How do I get pthreads to work in Windows? - c

I was running into errors such as those mentioned bellow when trying to compile code containing pthreads
warning: return type defaults to 'int' [-Wreturn-type]|
|In function 'print_message_function':|
warning: control reaches end of non-void function [-Wreturn-type]|
| undefined reference to `_imp__pthread_create'|
| undefined reference to `_imp__pthread_create'|
| undefined reference to `_imp__pthread_join'|
| undefined reference to `_imp__pthread_join'|
I'm running GCC on Windows 7 but I have mingw installed. I'm using the IDE Code::Blocks and select "compile current file". Here is a screen shot of the linker settings, I'm at a loss here
UPDATE: I added -pthread to the "Other linker options" and it works better. There still are problems. When I compile it says
|In function 'print_message_function':|
warning: control reaches end of non-void function [-Wreturn-type]|
and when I go to run it CodeBlocks says "it appears the program has not been built yet" and when I click on "build" I am shown this error
mingw32-g++.exe -o "SimpleExample.exe" "SimpleExample.o" -static-libgcc -static-libstdc++ -pthread
mingw32-g++.exe: error: unrecognized option '-pthread'
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 1 warnings (0 minutes, 0 seconds)
How do I fix this? I want to build/test on Windows but have the program run on a Unix environment. What is the difference between compile and build in an IDE?

this answer come late but ... it worked for me, so I decided to share it.
I downloaded the pthreads library from
ftp://sourceware.org/pub/pthreads-win32/pthreads-w32-2-9-1-release.zip
I unzipped it, then I copyed header files (.h) in
C:\ProgramFiles\CodeBlocks\MinGW\include
and library files in
C:\ProgramFiles\CodeBlocks\MinGW\lib
I copyed the dll files in the executable folder of my project
(myprojects/bin/debug in my case)
I added the -lpthreadGC2 option in the
Settings -> Compiler -> Linker Settings -> Other Linker Options
of my Code::Blocks IDE
Hope this can help.

It is -lpthread, not -pthread.
Edit:
Libraries can be added to the compile line in a couple of ways. If we have a file called (for example) /usr/lib/libpthread.so we could include the file like this:
cc -o myprog /usr/lib/libpthread.so myprog.c
or, alternatively:
cc -o myprog -lpthread -L /usr/lib myprog.c
Since /usr/lib is a standard directory, we don't normally require the -L option. At runtime we might have to set an environment variable:
export LD_LIBRARY_PATH=/usr/lib
but again, the standard libraries are defaulted, so you don't have to use this unless you are building your own or using 3rd-party libraries.

warning: control reaches end of non-void function [-Wreturn-type]|
Your main does not return a value. Add return 0; at the end of main.
| undefined reference to `_imp__pthread_create'|
You need to link with the thread library. Add -lpthread to the linker command line.

Here's what happens currently as of now when using MinGW Installation Manager (the mingw32 package manager for windows) under Windows with the following packages installed:
mingw32-libpthreadgc-dll
mingw32-libpthreadgce-dll
ERROR: gcc 5.3.0 fails linking pthread e.g.
c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../../mingw32/bin/ld.exe: cannot find -lpthread
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minute(s), 0 second
SOLUTION: include sources from MinGW Package Manager, too, i.e. also select
mingw32-libpthreadgc-dev
mingw32-libpthreadgce-dev
MinGW 4.9.2 does not show this effect. GCC 5.4 on Ubuntu also does not require the pthread sources to compile any code.
This one helped me out whilst other tries (using mingw32-libpthread-old or configuring linker settings) failed.

Related

How to install latest glibc (version 2.29) beside system installed one & compile a program?

Based on This Stackoverflow link I downloaded & installed glibc v2.29 in "/usr/local/glibc" path of Linux OS. Then based on this Stackoverflow link I tried to compile This Example, But I got following errors.
First Try Command:
gcc -Wall -g -o main main.c -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
First Try Error Log:
main.c:1:10: fatal error: threads.h: No such file or directory
#include <threads.h>
^~~~~~~~~~~
compilation terminated.
Second Try Command:
In second try, I am using "-I" & "-L" GCC command options.
gcc -Wall -g -I/usr/local/glibc/include -o main main.c -L/usr/local/glibc/lib -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
Second Try Error Log:
/tmp/ccCNYemW.o: In function `main':
/home/.../main.c:14: undefined reference to `thrd_create'
/home/.../main.c:16: undefined reference to `thrd_join'
collect2: error: ld returned 1 exit status
So I don't know where is the problem. Please Help me.
First of all, don't put an alternate libc (or alternate version of your libc) in a path searched by the normal include and library search (both link-time and runtime library search) for your main system one. This is a recipe for disaster. Installing a different glibc in /usr/local/ does avoid clobbering your system one, but now you just have two installed in places where the same tools can see and use them.
To do this right, you really need a full separate toolchain (gcc, binutils) in some completely separate path (like ~/my_glibc_root/... or /opt/alt_glibc_root/...). I'm not sure if there's a recommended way to do this. The glibc build procedures in Linux From Scratch might be a good place to look for ideas. In theory it can be done in a single stage; I do that with musl libc in musl-cross-make by careful use of intermediate make rules in the gcc build system. But applying the same idea to glibc probably requires some extra care.
Second Try Command: In second try, I am using "-I" & "-L" GCC command options.
gcc -Wall -g -I/usr/local/glibc/include -o main main.c -L/usr/local/glibc/lib -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
This command is almost correct. The thrd_create and thrd_join functions are defined in libpthread, which you didn't link against.
Add -pthread to your compile command, and the link should succeed.
P.S. R's advice of not installing alternate GLIBC into /usr/local is also a good one.

Compile a statically linked executable of the "stress-ng" package

I'm trying to compile the "stress-ng" package to produce a statically linked executable to use it inside GEM5 full system simulator.
A tarball of this package can be downloaded here. The version I'm trying to compile is 0.07.08.
To compile a dynamically linked executable of this package, just "make". This works for me.
However, since I need to run the "stress-ng" exe from within a GEM5 full system simulation, I need to make sure that the exe is self-contained. This is usually done using the "-static" CFLAG option, however, for "stress-ng", I get an error when I try this option.
Here is what to do in order to reproduce this error. Edit "Makefile" and add "-static" option at the end of line # 25. Line 25 should look like the following:
CFLAGS += -Wall -Wextra -DVERSION='"$(VERSION)"' -O2 -std=gnu99 -static
Save then make, you will see the error below:
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libpthread.a(lowlevellock.o): In function `__lll_lock_wait_private':
/build/eglibc-3GlaMS/eglibc-2.19/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:78: multiple definition of `__lll_lock_wait_private'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libc.a(libc-lowlevellock.o):(.text+0x0): first defined here
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libpthread.a(lowlevellock.o): In function `__lll_unlock_wake_private':
/build/eglibc-3GlaMS/eglibc-2.19/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:328: multiple definition of `__lll_unlock_wake_private'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libc.a(libc-lowlevellock.o):(.text+0x30): first defined here
collect2: ld returned 1 exit status
make: *** [stress-ng] Error 1
Finally, OS is Ubuntu 14.04 and cc version is 4.6.4.
Am I missing some other CFLAG option(s) here?
I've pushed a new fix to the stress-ng repo that now allows static linking. The issue was that -lc was before -lpthread, which caused the problem.
Pull the latest changes and then build with:
STATIC=1 make

cs107 makefile::cannot find -lrssnews

I am want to begin working on the 4th assginment, RSS searcher, of Online Stanford CS107 Programming Paradigms course. However, I am lagging at the very first step; I can not compile the prepared, to-work-on, unfinished program.
I get this error when I type make;
gcc rss-news-search.o -g -Wall -std=gnu99 -Wno-unused-function -g -lnsl -lrssnews -L/media/D/Programming/assn-4-rss-news-search-lib/ -o rss-news-search
/usr/bin/ld: cannot find -lrssnews
collect2: error: ld returned 1 exit status
Makefile:32: recipe for target 'rss-news-search' failed
make: *** [rss-news-search] Error 1
I have installed libexpat-dev.
Here is the link to the course, its the 4th programming assignment, RSS;
https://see.stanford.edu/Course/CS107
Thanks in advance
That the project comes with librssnews.a is good news. This file is a static library called rssnews and this is what you need to compile the project successfully!
Warning: you almost certainly don't need to follow these steps, go on reading to see why.
Put this file in your project's directory (the one you're running the build from) or in the lib directory, if the project contains one (if it doesn't, don't create one).
Run the build again. If it fails with the same error, go on to next steps.
Find out where the compiler normally looks for libraries by compiling a simple code with the -v flag. For example, gcc simple.c -v. You'll get tons of output that will contain the paths the compiler visited to link your program.
Copy the library file to one of these paths and run the build once again.
Given that the library search path is specified explicitly, you can simply put the library into /media/D/Programming/assn-4-rss-news-search-lib/ and skip the steps discussed earlier altogether. But if it wasn't, you'd probably have to follow them.

APUE.H Error Linux C programming

I'm trying to execute the below program-
Within APUE.3E -> filedir -> filetype.c (this comes by default when I downloaded APUE.3E. I didn't make any changes)
but when I compile this is the error I'm receiving:
myramya~/Documents/apue.3e/filedir$ gcc filetype.c -lm -o filetype
/tmp/cchPKE7K.o: In function main':
filetype.c:(.text+0x94): undefined reference to err_ret'
collect2: error: ld returned 1 exit status
I'm using Linux Ubuntu. I have installed APUE.3E in Documents folder. I have administrator permissions. I wrote a simple Hello.c program and executed using:
$ gcc hello.c -o hello
and it worked without any issues.
Your hello example works compiling in a single step with gcc because it does not call any functions in other files (except functions in the standard C library which allways gets linked in).
Your filetype.c makes calls to a function err_ret which is not within filetype.c but in some other source file.
When compiling bigger programs the work is usually done in two steps: First source files are compiled into object files by making one call to gcc with the flag -c for each source file. Then all object files are linked together with a single call to gcc with all object files. It is also possible to put object files together into libraries. Usually a Makefile is used to compile bigger projects.
Your specific case with apue.3e is well explained here: https://unix.stackexchange.com/questions/105483/compiling-code-from-apue

I compiled the LAPACK and BLAS but my system can not recognize the library

I am working on a project written in a mix of Fortran 90 and Fortran 77 and now need to link the LAPACK/BLAS libraries, from netlib.org, to the project, all in a Linux environment. I used the gfortran compiler flags OPTS = -O2 -fPIC -m64 in the given Makefile, and then made it using
make blaslib
make
And it finished normally, or at least I think so.
Then, I copied the files in /usr/local/lib and /usr/local/bin/ and /usr/local/lib64/
but it didn't work. I even used the option -L/path/to/lapack/liblapack.a and it didn't work also.
When I compile my code, I get the following error:
qrB.o: In function `qrfactorizeb_':
qrB.f90:(.text+0x64f): undefined reference to `zgeqp3_'
collect2: ld returned 1 exit status
make: *** [run] Error 1
I am really unsure what to make of this error. I tested it in 3 other workstations and it didn't help! Can anyone help me?
I had the same problem some time ago! Dual working with Windows and Linux and also ease of playing with options in Windows taught me something interesting!
Try compiling such as:
[...]$
ifort liblapack.a libblas.a libslatec.a *.o -o profmm
and as you know, it means that I want to use 3 libraries to compile and link my files into profmm output file. It has no syntax error, but it leads to a lot of errors like:
preconditioner3.o: In function factorb_':
preconditioner3.f:(.text+0x1add): undefined reference tozgetrf_'
.
.
preconditioner.o: In function factorpre_':
preconditioner.f:(.text+0x13a2): undefined reference tozgetrf_'
preconditioner.f:(.text+0x18bb): undefined reference to zgetri_'
zbesh.o: In functionzbesh_':
zbesh.f:(.text+0xb3): undefined reference to d1mach_'
zbesh.f:(.text+0xcf): undefined reference toi1mach_'
.
.
.
and many more errors indicating that ifort is unable to read my libraries even though they are here in my current directory!
But simply change the command as follow:
[...]$ ifort *.o liblapack.a libblas.a libslatec.a -o profmm
and it works fine with no error! So it means that now ifort can read my library (local ones)! Also note that changing the order of libraries are very important, and it depends on the order of usage of those subroutines inside the program. So always try to reorder the library chain to check for possible errors.
Hope it helps.

Resources