I need to compile libnetconf from https://github.com/CESNET/libnetconf for beaglebone. But the configure script gives error and exits.
last part of the log is
checking for xmlDOMWrapReconcileNamespaces in -lxml2... no
checking for xslt-config... yes
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... no
checking whether pthreads work with -pthreads... no
checking whether pthreads work with -mthreads... no
checking for the pthreads library -lpthread... no
checking whether pthreads work with --thread-safe... no
checking whether pthreads work with -mt... no
checking for pthread-config... no
configure: error: Missing POSIX threads support.
configure was run as follows
./configure --build=x86_64-linux --host=arm-linux-gnueabi --target=arm-linux-gnueabi --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib/libnetconf --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-libssh
libpthreads is present. What am i missing?
Related
I am working on cross compiling an experimental GNU free Linux toolchain using clang (instead of gcc), compiler-rt (instead of libgcc), libunwind (available at http://llvm.org/git/libunwind.git) (instead of libgcc_s), lld (instead of GNU ld), libcxx (instead of libstdc++), libcxxabi (instead of not sure, I'm unclear on the GNU distinction between libstdc++ and its ABI) and musl (instead of glibc).
Using a musl based gcc cross compiler and a few patches I've managed to successfully compile all of the above and sucessfully compile and link a simple hello world C program with it. Something seems to have gone wrong, however, as running the hello world program results in a segmentation fault:
$ ./hello
Segmentation fault
$
Normally I would simply debug it with gdb, but herein lies the problem:
$ gdb ./hello
Reading symbols from ./hello...Dwarf Error: Could not find abbrev number 5 in CU at offset 0x52 [in module /home/main/code/main/asm/hello]
(no debugging symbols found)...done.
(gdb) start
Temporary breakpoint 1 at 0x206
Starting program: /hello
During startup program terminated with signal SIGSEGV, Segmentation fault.
(gdb)
I can't seem to step through the program in any way, I'm guessing because the error is occuring somewhere in early C runtime startup. I can't even step through the assembly using layout asm and stepi, so I really don't know how to find out where exactly the error is occuring (to debug my toolchain).
I have confirmed that the problem resides with lld by using a GNU binutils ld to successfully link the hello world object (statically) using the cross compiled libraries and object files, which results in a functional hello world program. Since lld successfully links, however, I can't pinpoint where failure is occuring.
Note I compiled hello as a static executable and used the -v gcc/clang option to verify that all the correct libraries and object files were linked it.
Note online GDB documentation has the following to say about the above error:
On Unix systems, by default, if a shell is available on your target, gdb) uses it to start your program. Arguments of the run command are passed to the shell, which does variable substitution, expands wildcard characters and performs redirection of I/O. In some circumstances, it may be useful to disable such use of a shell, for example, when debugging the shell itself or diagnosing startup failures such as:
(gdb) run
Starting program: ./a.out
During startup program terminated with signal SIGSEGV, Segmentation fault.
which indicates the shell or the wrapper specified with ‘exec-wrapper’ crashed, not your program.
I don't think this is true, considering what I'm working with and that the problem doesn't happen when I use GNU ld, and because the suggested solution (set startup-with-shell off) doesn't work.
The croscompilling means that the compilation is done on a host machine, and the output of the compilation is the binary which shall run on a target machine. Therefore the compiled binary is not compatible with your host CPU. Instead, if your target supports this, you could run the binary there and use the debugger from your toolchain to connect to the running binary remotely if supported. Or alternatively, the debugger may also be available at the target and you can debug the binary already at place.
Just to get more feeling, try to use command file for the compiled binary, and some other binaries of your host to see possible differences.
I am porting a windows library to linux. I need to use timed join to wait for the thread to join in a specific timeout.
When I compile the library on Linux I am getting the warning
Implicit declaration of the function - pthread_timedjoin_np
I have included pthread.h and have compiled with -lpthread link. I know that pthread_timedjoin_np is a non-standard GNU function. The function first appeared in glibc in version 2.3.3. and somewhere in BCD v6.
I even checked the Man Page for Linux but got no help. How do I avoid this warning? Any help?
Edit-1:
My system is RedHat 5.
Make sure the #define _GNU_SOURCE is before any of the your headers are included. Macros are set up by <features.h>, which include various parts of the GNU C library. If you've included other headers before you define _GNU_SOURCE, <features.h> will have already been included and will have not seen _GNU_SOURCE.
Even easier, just define it with the compiler adding -D_GNU_SOURCE as a compiler flag.
I am trying to port some code I wrote from Mac OS X to Linux and am struggling to find a suitable replacement for the OSX only OSAtomic.h. I found the gcc __sync* family, but I am not sure it will be compatible with the older compiler/kernel I have. I need the code to run on GCC v4.1.2 and kernel 2.6.18.
The particular operations I need are:
Increment
Decrement
Compare and Swap
What is weird is that running locate stdatomic.h on the linux machine finds the header file (in a c++ directory), whereas running the same command on my OSX machine (gcc v4.6.3) returns nothing. What do I have to install to get the stdatomic library, and will it work with gcc v 4.1.2?
As a side note, I can't use any third party libraries.
Well, nothing is there to stop you from using OSAtomic operations on other platforms. The sources for OSAtomic operations for ARM, x86 and PPC are a part of Apple's libc which is opensource. Just make sure you are not using OSSpinLock as that is specific to Mac OS X, but this can be easily replaced by Linux futexes.
See these:
http://opensource.apple.com/source/Libc/Libc-594.1.4/i386/sys/OSAtomic.s
http://opensource.apple.com/source/Libc/Libc-594.1.4/ppc/sys/OSAtomic.s
http://opensource.apple.com/source/Libc/Libc-594.1.4/arm/sys/OSAtomic.s
Alternatively, you can use the sync_* family, which I believe should work on most platforms, which I believe are described here: http://gcc.gnu.org/wiki/Atomic
The OpenPA project provides a portable library of atomic operations under an MIT-style license. This is one I have used before and it is pretty straightforward. The code for your operations would look like
#include "opa_primitives.h"
OPA_int_t my_atomic_int = OPA_INT_T_INITIALIZER(0);
/* increment */
OPA_incr_int(&my_atomic_int);
/* decrement */
OPA_decr_int(&my_atomic_int);
/* compare and swap */
old = OPA_cas_int(&my_atomic_int, expected, new);
It also contains fine-grained memory barriers (i.e. read, write, and read/write) instead of just a full memory fence.
The main header file has a comment showing the operations that are available in the library.
GCC atomic intrinsics have been available since GCC 4.0.1.
There is nothing stopping you building GCC 4.7 or Clang with GCC 4.1.2 and then getting all the newer features such as C11 atomics.
There are many locations you can find BSD licensed assembler implementations of atomics as a last resort.
I need to find out the available (installed in the system) GCC version (Major and minor) inside the execution of a c program (in runtime). Meaning, programatically extract the version of the available gcc (same as if I was in a shell and typed gcc --version, but in a c program).
The __GNUC__ and __GNUC_MINOR__ are only useful in compile time and I've found the gnu_get_libc_version() function from gnu/libc_version.h, but it only gets me the libc version and I need the GCC version. If there is something similar for GCC it would be great...
I would really like to avoid calling a shell command to do this.
There is a simple way:
$ gcc -dumpversion
4.6
Invoke the gcc shell command with the parameter --version; it's the correct way to do this. See popen() to do that.
Or you can invoke GCC with to compile a program which prints the values for __GNUC__ and __GNUC_MINOR__. But that will not work if the GCC in question is configured for cross compilaton.
Alternatives would be to search the binary for version strings and hoping that you get the right one, that the format doesn't change and that the version string is distinct enough for you to recognize it with enough confidence.
In 1.5 words: Don't.
I need to find out the available (installed in the system) GCC version (Major and minor)
What are you going to do with the information?
You can't get a meaningful answer to your question, because
The user may not have any GCC installed in /usr/bin
May have 5 different versions installed elsewhere on the system
May have a version in /usr/bin which pretentds to be gcc-X.Y, but is actually gcc-Z.W, or Clang, or icc, etc.
But if you insist on getting a meaningless answer, popen("gcc --version") and parse the resulting output.
I had written a small thread program when i compiled cc filename.c, i got some statements during compilation, but when i compiled using -lpthread (cc filename.c -lpthread) it got executed what is this -lpthread why is it required? can anyone explain this in detail. it would be of great help.
The pthread_create() function that you use in your program is not a basic C function, and requires that you use a library.
This is why you have to use this command switch -lpthread.
This gcc command tells him to look for a library named libpthread somewhere on your disk, and use it to provide the thread creation mechanisms.
I suggest you read this to get familiar with the "library" concept: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
The -l option is typically used to specify a library (in this case, the pthread library) that should be linked with your program.
Since the thread functions often live in a separate library, you need an option like this when building a program that uses them, or you will get linker errors.
pthread is something called POSIX Threads. It's the standard library for threads in Unix-like POSIX envirnoments.
Since you are going to use pthread you need to tell the compiler to link to that library.
You can read more about exactly what lpthread is and how it works: https://computing.llnl.gov/tutorials/pthreads/