Windows XP:
I ultimately wanted to install DDD (the debugger). Its not available in binary form for Windows. When I got its source and tried to configure it, it complained that no term caps library was present. So I acquire ncurses and got this after a mostly successfull build using Cygwin Terminal:
../lib/libncurses.a(lib_ttyflags.o)(.text+0x41):lib_ttyflags.c: undefined reference to `_nc_mingw_ioctl'
../lib/libncurses.a(lib_ttyflags.o)(.text+0xd1):lib_ttyflags.c: undefined reference to `_nc_mingw_ioctl'
It works for me when I do this:
configure --enable-term-driver --enable-sp-funcs
make
The --enable-term-driver was needed for "mingw" (I tested on msys, but this should work equally well on cygwin), and --enable-term-driver requires --enable-sp-funcs.
--enable-sp-funcs
compile-in support for extended functions which
accept a SCREEN pointer, reducing the need for
juggling the global SP value with set_term and
delscreen.
--enable-term-driver
compile with terminal-driver. That is used in the
MinGW port, and (being somewhat more complicated)
is an experimental alternative to the conventional
termlib internals. Currently, it requires the
sp-funcs feature to be enabled.
See here: http://lists.gnu.org/archive/html/info-gnu/2011-02/msg00020.html
Related
I've written a program in Haskell that's going to be run on a Windows 7 machine. It's not my machine. I don't get to choose the OS.
It's been written using the ncurses package, and compiles just fine on my (Ubuntu) machine. Unfortunately, it won't compile on Windows, even under Cygwin. It gives me a very unhelpful error (Process exited with code: ExitFailure 1) when it tries to build the ncurses package.
I've tried specifying the exact locations of the header and dll files for ncurses to no avail.
Is there anything I can do, short of re-writing the software to use a different package?
In hindsight, I should've checked that it would compile under Windows some time ago, but since I've successfully used ncurses in C on Windows in the past, I had no reason to believe it wouldn't work.
My current code is available on GitHub.
Edit: If I were to re-write the IO parts using something else (as an absolute last resort) I would need to be able to do the following things:
determine the number of rows and columns in the terminal
be notified if the terminal is resized
be notified when a key is pressed (including arrow keys and function keys, without line buffering)
control the position and visibility of the cursor
disable echoing of standard input
change text/background colour
...and I would need to be able to do these things in both Windows and Linux.
I need a debug version of glibc.I have some doubts regarding the installation of glibc-2.29 from source in kali linux.Based on the post https://www.tldp.org/HOWTO/html_single/Glibc-Install-HOWTO/,
To install glibc you need a system with nothing running on it, since many processes (for example sendmail) always try to use the library and therefore block the files from being replaced. Therefore we need a "naked" system, running nothing except the things we absolutely need. You can achieve this by passing the boot option
init=/bin/bash to your kernel.
it says that we need to install the glibc in a single usermode environment.In another post https://www.tldp.org/HOWTO/Glibc2-HOWTO-5.html
single usermode is not required for installation but backing up the old libraries.I dont know which one to follow.Can anyone help?
I found that we can use glibc without installing but building from source by adding '-g' flag in ./configure and setting LD_LIBRARY_PATH varible as follows after building
LD_LIBRARY_PATH=/path/to/the/build_directory gdb -q application
Note: this solution only works when the system GLIBC and the built-from-source GLIBC exactly match, as explained here.
I need a debug version of glibc.
Most distributions supply ready-made libc6-dbg packages that match your installed GLIBC. This is the best approach unless you are a GLIBC developer (or plan to become one).
I have some doubts regarding the installation of glibc-2.29 from source in kali linux.
Installing / replacing system libc is almost guaranteed to render your system unbootable if there are any mistakes. Recent example.
Before you begin, make sure you either know how to recover from such a mistake (have a rescue disk ready and know how to use it), or you have nothing of value on the system and can re-image it from installation media in the likely case that you do make a mistake.
The document you referenced talks about upgrading from libc5 to libc6. It was last updated on 22 June 1998, and is more than 20 years old. I suggest you find some more recent sources. Current documentation does suggest doing make install while in single-user mode.
I use gopacket in my program. on linux, it runs perfectly.
But on windows the whole program crashes if i did not install WinPcap before.
My plan was to check if WinPcap is installed, and if not to inform the user that he needs this to use 100% of all features.
But i dont come to this point. i cant use gopacket if WinPcap is not available. I mean... not a single line of code of it (=> crash)
Has anyone an idea how i can solve this? im do not need gopacket actually. My plan was, if it is installed, fine, super! If not, dont care... do other things.
But now i have 2 choices... remove gopacket totally or find a way to start my program without the need of wpcap.dll. at least to tell the user that he needs it.
Please help me :(
You're wrong in that you are «not [using] a single line of code of it»: it's not hard to see that
its Windows-specific code calls into winpcap.dll.
What is more fun, is that
its Unix-specific code calls into libpcap.so, and this means you have it working on your local system simply due to the fact you have libpcap package installed (or whatever it's named in your code).
All this means that currently your program is not really portable
anyway (I mean, in the sense you supposedly think it is portable).
You can run something like
$ ldd ./yourbinary
and see it printing a reference to libpcap.so of some version.
There are several ways to solve this.
The easiest is to just try shipping winpcap.dll with your binary. Windows by default looks for DLLs in the current directory of the application trying to load them. Since gopacket uses cgo, it means the winpcap.dll is attempted to be linked it at the application startup, so the application has no chance of changing its working directory before that library is attempted to be found and linked in.
A more complicated approach is to make (or obtain) a static version of the winpcap library (remember that DLL is a library, just a special form of it) and then jump around building gopacket so that it picks that static library.
Install Npcap in "Wpcap API compatibility mode".
I've just compiled BPF examples from kernel tools/testing/selftests/bpf and tried to load as explained in http://cilium.readthedocs.io/en/v0.10/bpf/:
% tc filter add dev enp0s1 ingress bpf \
object-file ./net-next.git/tools/testing/selftests/bpf/sockmap_parse_prog.o \
section sk_skb1 verbose
Program section 'sk_skb1' not found in ELF file!
Error fetching program/map!
This happens on Ubuntu 16.04.3 LTS with kernel 4.4.0-98, llvm and clang of version 3.8 installed from packages, iproute2 is the latest from github.
I suspect I'm running into some toolchain/kernel version/features mismatch.
What am I doing wrong?
I do not know why tc complains. On my setup, with a similar command, the program loads. Still, here are some hints:
I think the problem might come, as you suggest, from some incompatibility between kernel headers version and iproute2, and that some relocation fails to occur, although on a quick investigation I did not find exactly why it refuses to load the section. On my side I'm using clang-3.8, latest iproute2, but also the latest kernel (some commit close to 4.14).
If you manage to load the section somehow, I believe you would still encounter problems when trying to attach the program in the kernel. The feature called “direct packet access” is only present on kernels 4.7 and higher. This is what makes you able to use skb->data and skb->data_end in your programs.
Then as a side note, this program sockmap_parse_prog.c is not meant to be used with tc. It is supposed to be attached directly to a socket (search for SOCKMAP_PARSE_PROG in file test_maps.c in the same directory to see how it is loaded there). Technically this does not prevent one to attach the program as a tc filter, but it will probably not work as expected. In particular, the value returned from the program will probably not have a meaning that tc classifier hook will understand.
So I would advise to try with a recent kernel, and to see if you have more success. Alternatively, try compiling and running the examples that you can find in your own kernel sources. Good luck!
I'm trying to get Wanderlust working in Windows to connect to Gmail. Compiling the code is much more painful than expected. Here are the barriers so far:
Can't download dependent packages: SEMI, APEL, and FLIM. I eventually found newer versions, but I'm not sure they will work. Anyone have the older versions?
Needs make and install. I used MSYS and it seems to have compiled okay.
SSL support. I was getting a "Cannot open load file: ssl" error. I found an ssl.el that comes with w3. So installed w3.
Bash command in ssl.el: ssl-get-command is running something from /bin/sh (not a directory I have in Windows). I really don't want to refactor this code. Is there a better way?
Others speak very highly of Wanderlust, so I want to give it a try. I feel like I'm almost there, but am pretty much worn out with all the crazy configuration I have to do. Does anyone have this working on Windows? I'm pretty sure it will work with Gmail, because of this post. But will it work in Windows too? If you have a few pointers, please help.
ssl.el is part of wanderlust. Just look in the wanderlust/utils directory.
For STARTTLS you may either use the starttls or gnutls-cli programs.
Unfortunately, both of these programs use signals (SIGALRM to be precise) which are not supported on Windows.
You need to use the Cygwin ports of these programs -- not MSYS!
Additionally, if you're using a Windows port of Emacs (ie. not Cygwin's emacs) you need to modify starttls.el (which is part of GNU Emacs) because the signal-process function doesn't do anything regarding SIGALRM. Replace all instances of
(signal-process (process-id process) 'SIGALRM)
with
(call-process kill-program nil nil nil
"-ALRM" (format "%d" (process-id process)))
and initialize kill-program somewhere apropriately to point to cygwin's kill.exe:
(setq kill-program "c:/cygwin/bin/kill.exe")
If you want to use SSL you have to set ssl-certificate-verification-policy to a value greater than 0. Otherwise connecting to Gmail would fail.
Using the wl configuration here:
http://box.matto.nl/emacsgmail.html
After adding ssl.el from here:
http://quimby.gnus.org/cgi-bin/cvsweb.cgi/gnus/contrib/ssl.el
I am able to get wanderlust talking just fine to gmail on a linux configuration of wanderlust, and since the ssl.el file there isn't really system-dependent (although it does require the openssl command-line tools), I don't see that there should be any problem with it working on msys.
The 'cannot open load file: ssl' error is exactly what I ran into until I installed that ssl.el file too :)
Edit; Just in case you have trouble finding it, the MSYS port of openssl you'll want is here:
http://sourceforge.net/projects/mingw/files/MSYS%20openssl/
[posted as a new answer since I think you'll get a notification that way :)]
I recently installed wl on a linux host, and had the same issue with not being able to locate the dependencies as specified. However, I, like you, found the 'more recent versions' and used them. They did indeed work fine, so unless those new versions have added any incompatibility with windows, they shouldn't present any problem.
The error you're receiving is because it's not finding the 'install' utility, which is part of GNU coreutils. Autotools (and it's family) depend on install being able to work, so if you want to continue with the cygwin method, then installing autotools should bring in the install program.
(I have no idea if wl will compile/work using cygwin otherwise, though.)