I'm trying to write the basic plugin for wireshark.
I wrote the basic # foo # dissector(packet-foo.c) as per
https://www.wireshark.org/docs/wsdg_html_chunked/ChDissectAdd.html
and then I added and Modified all the file as per
doc/README.plugins
After Modifying all the files It says to Run autogen.sh.
I run it on my command prompt like
C:\Development\Wireshark>./autogen.sh
It says
'.' is not recognized as an internal or external command,
operable program or batch file.
** Am I missing something ? **
Am I missing something ?
Yes, you're missing the fact that Windows and UN*Xes are different operating systems with different toolchains and different build systems, which means that the autotools (automake, autoconf, etc.) aren't used on Windows. :-)
And README.plugins is missing that fact as well. :-( I've filed Wireshark bug 11236 on that.
Try just running nmake -f Makefile.nmake in the top-level directory.
Related
I'm trying to follow the tutorial about how to set sphinx and Readthedocs together for project. I used Sphinx back in the day while in a internship, with ubuntu and the setup was quite seamless. I've just launched the sphinx-quickstart on my anaconda power shell. When I try to run make html the following error appears:
(base) PS D:\code\RaspberryServer\docs> make html
make : The term 'make' is not recognized as the name of a cmdlet, function, script file, or operable program. Check
the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ make html
+ ~~~~
+ CategoryInfo : ObjectNotFound: (make:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Suggestion [3,General]: The command make was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default. If you trust this command, instead type: ".\make". See "get-help about_Command_Precedence" for more details.
Firstly I thought it was because I had never installed MinGW. But even after doing so I don't seem to fix the problem and I have no clue to how to start looking into it. My python installation is fully based on Anaconda.
Expand the comment above.
The default site generated by sphinx assumes you use make html on multiple operating systems to generate HTML pages.
That's achieved by typical assumption that,
You are on macOS or Linux with (GNU) make installed, so make html executes the task defined in Makefile.
You are on Windows and at command prompt (cmd.exe), so make html actually calls to make.bat.
However, you are launching PowerShell console ("PS D:" indicates that), so you cannot get make html working properly. PowerShell does not know what to do with make, and won't call make.bat automatically. You need to call .\make.bat html instead.
You may try to use sphinx-build. As far as I know it gets the job done and does not depend on the OS you use.
sphinx-build <sourcedir> <outputdir>
I am running into issues setting up go for the first time on a Windows 10 machine.
I followed the instructions from the install. https://golang.org/doc/install?download=go1.10.windows-386.msi
When I CD to my project E:\goProjects\goWebApp\src and run go build, I receive the following error.
C:\windows\system32>go version
Not in an environment
C:\Users\MyUser~1\AppData\Local\Temp\go_there.bat' is not recognized as an internal or external command,
operable program or batch file.
My system variables are as follows:
GOPATH=E:\goProjects\goWebApp
GOROOT=C:\Go
PATH=C:\Go\bin
If I run go version from C:\Go\bin everything works fine. Running go command from anywhere outside of this directory does not work. I have also tried restarting my cmd prompt and restarting my computer. Still no luck. Has anyone else ran into this issue? Or know what I might have done wrong?
Turns out I had two go locations in my PATH (sort of). When I ran the command where go from command prompt two paths were returned.
Something like this..
C:\tools\devTools\bin
C:\Go\bin\go.exe
There apparently was a bat file in devTools\bin called go.bat. This was unrelated to golang itself, just coincidental naming unfortunately.This was executing instead of the go binary, which in return was throwing the random error with the Not in an environment message.
To fix the issue I just removed the devTools path from my PATH variable for now.
I am trying to build my software using cygwin-x86(32 bit version) on Windows-7.
Cygwin-x64(64 bit) works perfectly fine on the same machine. I want to build 32-bit executable.
Whenever I try cygwin-x86, I get the following errors:
[main] make 7780 child_info_fork::abort:
C:\cygwin\bin\cygiconv-2.dll: Loaded to different address:
parent(0x440000) != child(0x5F0000) make: fork: Resource temporarily
unavailable
I have checked this thread Cygwin Error
I have already tried everything mentioned in there, but I still continue to face the same issue.
Whenever i try /usr/bin/rebaseall -v or cd /usr/bin && ./rebaseall -v as mentioned in the step 7 of the accepted answer in the above mentioned thread, I get this error:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygvtv_stubs-0.dll: skipped
because wrong machine type.
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll: skipped because wrong
machine type. Segmentation fault (core dumped)
I get this wrong machine type error for a lot of other .dll's as well.
As mentioned earlier I have cygwin-64 installed on my machine & working as expected. But while running rebaseall it is somehow looking for x86-64-pc-cygwin instead of 32 bit version.
The thread is obsolete.
run /usr/bin/rebase-trigger, close all cygwin processes and run again setup-x86.exe. Also without installing anything will execute a rebase for you.
You can also specify the option full.
Additional note:
The most likely cause of fork problems on 32 bit system are too many programs and libraries installed.
for example:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll
belongs to cygwin64-zlib a cross library for building cygwin64 programs from cygwin32. Do you really need it ? If not, as I suspect, remove all cywgin64 packages .
The problem can also be triggered by an anti-virus program. (I saw it happening with Avast.) You can test if this is the cause by disabling it.
Could also be caused by this update
https://support.microsoft.com/en-us/help/4561616/windows-10-update-kb4561616
You can also kill each of the latest process of ash, dash or bash that was forked, setup.exe will simply skip this script and continue with the rest.
I had to kill about 10-20 of them, mostly in latex postinstall scripts.
For me, the solution was to remove the .new file extention of the libs from c:\cygwin64\bin\
I had the same problem using git. various dlls depending on the git command used where included in the error message stating that it was loaded to "different adress".
In fact a corporate antivirus or a loaded program had probably prevent un update during the rebase phase while installing a new program (git-svn in my case)
some required libraries where not installed but cleverly left in the target with the .new file extention.
I just had to remove the .new extention (and rename the original lib to .old) to solve the problem.
In my case the list of lib involved was:
cygcrypto-1.1.dll
cyggcc_s-seh-1.dll
cygintl-8.dll
cygwin1.dll
I have been trying to build the freetype2 library in OSX Mavericks for several weeks now, but without success.
The trouble is with using GNU Autotools to create the configure build script.
I have installed automake, autoconf, libtoolize, m4 and perl5 using the macports port command.
When executing aclocal, there is supposed to be a file created in the configure directory that contains Autotools macros: aclocal.m4. However, this file is not being output, and the subsequent glibtoolize and autoconf commands are generating a spurious configure script.
The result is: no aclocal.m4 file, and the usual contents of ./autom4te.cache/traces.* being dumped at the top of the generated configure file (the traces.* files are empty).
e.g.:
m4trace:configure.ac:14: -1- AC_SUBST([SHELL])
m4trace:configure.ac:14: -1- AC_SUBST_TRACE([SHELL])
m4trace:configure.ac:14: -1- m4_pattern_allow([^SHELL$])
Any help would be greatly appreciated.
GNU Autotools does not support execution over a working directory stored on a FAT32 file system. It results in spurious m4trace debug messages being output to the generated configure script.
It is unknown why this is, but may be related to the reliance on the sleep command to check whether a file has changed. FAT32 rounds time stamps to the nearest second, where execution and subsequent modification checks may happen on a sub-second timescale.
This has been raised with the development team, but for now, I move my working directory to my OSX boot partition before executing GNU Autotools.
I'm trying to deploy my site using Fabric and Mercurial. In the Windows command line, running hg push works perfectly with no problems.
But when I try writing
local("hg push")
in a fabfile and running it, I get the error:
'"hg push"' is not recognized as an internal or external command, operable program or batch file.
Googling gave me an idea that it might be a problem with the PATH variable in Python subprocesses, for example here: Why would an "command not recognized" error occur only when a window is populated?.
Can you help me out? Is the bug in Fabric or in my own code?
Thanks.
As Chris R mentions, we don't do a ton of Windows support as none of the core devs are Windows users; we have to rely on reports and suggestions from our more savvy Windows users.
It sounds like this could be related to this recently fixed, but not released, bug -- it will be in Fabric 1.0.2 which should be out soon. If you're feeling brave, you can test it out now via:
pip install -e git+git://github.com/bitprophet/fabric#1.0#egg=Fabric
If you then do fab -V, it should say it's 1.0.2a -- if so, running your fabfile may work better. Please let us know if you do this!
It sounds like the you need to add Mercurial to the Fabric process's PATH.
Maybe something like:
fabric.context_managers.path(<path to your hg.exe>)
run('hg push')
See the docs for the path context manager. It wasn't clear if path applies to local commands, but run commands are explicitly referenced.
Neither of the fixes provided worked, but changing
local("hg push")
to
os.system("hg push")
solved the problem.