I'm trying to install samtools () on cygwin.
I followed the various tricks here and here but looks like my problem is that i can't have a functioning pthread.
gcc is installed and works, zlib is installed and works and ncurses is installed and works + everything was added to the $PATH...but when i run make and it gets to the following line in Makefile:
gcc -pthread $(LDFLAGS) -o $# $(AOBJS) libbam.a $(HTSLIB) $(LDLIBS) $(LIBCURSES) -lm -lz
then it throws an error because it doesn't recognize the unix command -pthread. now...pthread should be a part of the default installation in cygwin so I don't understand why this is not working...
any hint would be great!
gcc's option -pthread is not available on Cygwin.
Related
I have an installation of DPDK and I'm trying to compile code with it. This worked on my WSL machine, however on the test server, with the same install of dpdk, I'm getting the error:
/usr/local/include/rte_mempool.h: error: unknown type name 'ssize_t'
I've noticed this header does not include /sys/types.h, but it also doesn't include that on the machine that this works on. I don't know where it's supposed to come from, but it's coming from somewhere.
How do I get these headers to be aware of ssize_t?
As noted in a comment:
The compiler options include -std=c99 -O3 -march=native -I/usr/local/include -include rte_config.h, and a whole bunch of -l options (dpdk's make structure adds these in). This prompted me to run gcc --version and the working one is Ubuntu gcc 9.3.0 and the broken one is gcc 5.4.0. Seems like it might be an incompatibility between dpdk and the gcc installed.
As mentioned in the comments by #JonathanLeffier, the root cause of the issue is including sys/types.h when gcc option --std=c99 is passed. The easiest fix without modifying the DPDK or sample code is to include the path to types.h as part of cflags.
If the native build is for x86_64 target, follow these steps:
execute find /usr/include/ -name types.h to identify the right file for local build (this is because the current cflags has -march=native)
modify the CFLAGS from -std=c99 -O3 -march=native -I/usr/local/include -include rte_config.h to -std=c99 -O3 -march=native -I/usr/local/include -include rte_config.h --include=/usr/include/[target-machine]/sys/types.h
Note: In my humble suggestion please use pkg-config for populating the right CFLAGS and LDFLAGS for both shared and static binary.
I am unsure of what could be causing this as I have tried recompiling libcurl and using pre-compiled binaries.
My compiler command
x86_64-w64-mingw32-gcc -Wall -Lwin-lib -Iwin-lib -I./ -D WIN32 -D CURL_STATICLIB -mwindows ... -o win-export/SLM.exe -lm -lraylib -ltmx -lxml2 -lzlibstatic -lcurl
There aren't any compiler errors or linker errors. Is this a problem with my compiler? Or one the other libraries I am using?
I have a program wrote back when I was still at university, and it was running fine on ubuntu 16.04. Today I was trying to compile it on my Mac which is running OS version 11.2.3, and got the following error: "symbol(s) not found for architecture x86_64."
I did some research, it seems that this error is related to makefile, but I cant figure out what is wrong. Here is what I have in Makefile:
lander: lander.o
gcc -std=c99 -Wall -o lander lander.o -lm -lncurses
lander.o: lander.c
gcc -std=c99 -Wall -c lander.c -g
clean:
-rm -f *.o lander core
First time asking a question here, if the format of my text looks bad, I apologize in advance. Thank you.
I installed the latest version of MinGW and trying to compile the project:
\MinGW\bin\gcc.exe -O3 -flto -Wall -msse src/*.c -o noname -lm -lpthread
But nothing happens. No errors, no exe files, nothing.
I am not familiar with Windows in terms of compilation.
This is a simple console application that is compilable on Ubuntu without problems with the same command.
What I am doing wrong?
I am running Ubuntu 12.04 and I'm currently working on a project involving C, OpenGL, a teapot and input methods.
The problem started when I decided to have arrow keys as input. I checked to see the key codes for arrow keys but all of the arrows return 0. I looked up how to get this to work and I found conio.h. Unfortunately, it is an old DOS header that is not available for Linux. Then I found a substitute called ncurses.
After installing the necessary libraries, by following the build instructions closely, I #included curses.h in my main.c source. When I first tried to compile using gcc, I got the following errors:
main.o:main.c:function _Key: error: undefined reference to 'stdscr'
main.o:main.c:function _Key: error: undefined reference to 'wgetch'
main.o:main.c:function _Key: error: undefined reference to 'stdscr'
main.o:main.c:function _Key: error: undefined reference to 'wgetch'
I found a fix by adding -lncurses to the makefile like so:
SOURCES=main.c
main: main.o
gcc -lm -lGL -lGLU -lglut -lncurses main.o -o main
main.o: main.c
gcc -lm -lGL -lGLU -lglut -c main.c
But I was greeted by another error:
/usr/bin/ld: error: cannot find -lncurses
As well as the previous errors.
I have spent the last 2 days searching both the Ubuntu forums and StackOverFlow. Any help would be appreciated.
P.S. I don't know if this is important but when I try to run /usr/bin/ld I get this error:
ld: fatal error: no input files
For anyone with the same problem I had: I was missing the 32 bit libraries; I was compiling 32 bit on a 64 bit server which was missing the lib32ncurses5-dev package.
On Ubuntu I simply ran:
sudo apt-get install lib32ncurses5-dev
First off, you should put the libraries after the object file when linking. And not have them at all in the compilation of of the source file.
After that, if ncurses is not installed in a standard search folder you need to point out to the linker where it is, this is done with the -L command line option:
gcc main.o -o main -L/location/of/ncurses -lm -lGL -lGLU -lglut -lncurses
Try installing the ncurses-static package too, if you have only the ncurses-devel package installed in your Ubuntu OS.
If that solves your problem, plus if you add #Joachim's compiling instructions, you are off to a great start.
gcc main.o -o main -L/location/of/ncurses -lm -lGL -lGLU -lglut -lncurses
The linker can't find your shared library in it's search path. If you add the directory where your shared lib is to the LD_LIBRARY_PATH environment variable the linker should find it and be able to link against it. In that case you could omit the -L option to gcc:
gcc main.o -o main -lm -lGL -lGLU -lglut -lncurses
And it should compile fine.
EDIT:
Good to know that apt-get install libncurses5-dev fixes your problem.
FYI.
The LD_LIBRARY_PATH environment variable contains a colon separated list of paths that the linker uses to resolve library dependencies at run time. These paths will be given priority over the standard library paths /lib and /usr/lib. The standard paths will still be searched, but only after the list of paths in LD_LIBRARY_PATH has been exhausted.
The best way to use LD_LIBRARY_PATH is to set it on the command line or script immediately before executing the program. This way you can keep the new LD_LIBRARY_PATH isolated from the rest of your system i.e. local to the current running running instance of shell.
$ export LD_LIBRARY_PATH="/path/to/libncurses/library/directory/:$LD_LIBRARY_PATH"
$ gcc main.o -o main -lm -lGL -lGLU -lglut -lncurses