As a follow up question to my last one, is there any simple way to tell if a given C library is installed on a given machine (not programattically, just as a once off sort of thing)? I need to use libuuid, but I'm not sure if it's installed on the machines in question. The only two ways I can think of are:
1) Try to compile the code there (more work than I'd like to do)
2) Try something like "man libuuid" although seems like this wouldn't always be reliable if for some reason the manpages didn't get installed.
Is there some better other way?
Have you considered using autoconf? It's designed to check and see whether the build environment is set up correctly.
The simplest way is to invoke ld with the -l option. This will effectively test the existence of the library, searching the standard library locations automatically:
$ ld -luuid
ld: warning: cannot find entry symbol _start; not setting start address
$ echo $?
0
$ ld -luuidblah
ld: cannot find -luuidblah
$ echo $?
1
# so...
$ ld -luuid 2>/dev/null && echo "libuuid exists" || echo "libuuid not found"
EDIT
As dreamlax pointed out, this does not work for all unix variants. I don't know if it will work on all unixes (I've tested linux and OpenBSD) but you can try this instead:
$ echo "int main(){}" | gcc -o /dev/null -x c - -luuid 2>/dev/null
$ echo $?
0
$ echo "int main(){}" | gcc -o /dev/null -x c - -luuidblah 2>/dev/null
$ echo $?
1
Here's what I did using autoconf, which I'm showing here as a solid example for whoever else might come by next:
I created the file configure.ac which contained the following:
AC_INIT(package, 1.1, email)
AC_CHECK_LIB(uuid, uuid_generate_random, [echo "libuuid exists"], [echo "libuuid missing"])
I then ran the following commands in order (same folder I made configure.ac):
autoconf
./configure
At the end of the configure, it spat back whether or not it had found uuid_generate_random in the uuid library. Seemed to work perfectly (although unfortunately, two of the OSes were missing the library, but that's a whole other problem).
For anybody who may find this after the fact, the AC_INIT arguments here are throwaways and you can copy them wholesale. The arguments to AC_CHECK_LIB are: library name, the name of a function in that library, what to do on success, what to do on failure.
Even though Mehrdad's answer wasn't quite as helpful as I would have liked (i.e. to not have spent time trolling the docs) it seems to be the correct one and I'll be accepting it. mhawke: I really liked your answer, but I wasn't quite sure how to test to make sure it worked. It seemed to on SunOS, but always said no on the other two (AIX, HPUX) and I couldn't seem to come up with a library off the top of my head I could guarantee it would find.
Thanks for the help guys.
The autotools, as mentioned, checks for symbols within libraries. The way it does it is somewhat simple. As you mention in 1), autoconf, and its result the configure script, basically creates a dummy c program and attempts to link with the library in question. If it works, the library works, if it fails, obviously it wont work. Autoconf looks for specific symbols/function names in the library though.
Related
This question is related to Why does pclose return prematurely?. I'd like to find out what version of libc is used for a cross-compiled executable. There are limitations, described below, that make the answers at Check glibc version for a particular gcc compiler not apply.
One proposed way to check the libc version is to use the gnu_get_libc_version() function declared in gnu/libc-version.h. My cross-toolchain does not include libc-version.h.
Another proposed solution is to use the -print-file-name gcc option. This answer in the linked question just flat-out didn't work for me:
$ /path/to/toolchains/ARM-cortex-m3-4.4/bin/arm-uclinuxeabi-gcc -print-file-name=libc.so
libc.so
$
$ /path/to/toolchains/ARM-cortex-m3-4.4/bin/arm-uclinuxeabi-gcc -print-file-name=foo.bar
foo.bar
$ # I really do not have a foo.bar file in existence
Another proposed solution is to just do ldd --version. My target platform doesn't have ldd:
$ ldd
sh: can't execute 'ldd': No such file or directory
Another proposed solution is to look at __GLIBC__ and __GLIBC_MINOR__ -- but these also appear to come from libc-version.h, which doesn't exist in my cross-toolchain, as described above.
My cross-toolchain seems to only provide libc.a, not libc.so.
I tried running that libc.a through /path/to/toolchains/ARM-cortex-m3-4.4/bin/arm-uclinuxeabi-nm and strings grepping (case-insensitive) for "version" and "libc" but did not find anything that looked like an identifying version.
The last thing I tried was strings /path/to/toolchains/ARM-cortex-m3-4.4/bin/arm-uclinuxeabi-gcc | grep GLIBC, which gave me:
GLIBC_2.3
GLIBC_2.2
GLIBC_2.1
GLIBC_2.0
EGLIBC configuration specifier, serves multilib purposes.
But that solution wasn't highly upvoted, and it also has a comment suggesting that it doesn't really give you the version. I don't really understand this answer or its responding comment, so I don't know what to make of its validity.
Question: given all the above, is there any definitive way to determine the libc version used for cross-compiling for this cross-platform?
You might be dealing with a variant of libc other than glibc. There are multiple different implementations of libc, such as musl or uclibc.
Here's a Bash script which can detect whether your compiler is using glibc or uclibc, and tells you the version if it detects either.
GCC_FEATURES=$(gcc -dM -E - <<< "#include <features.h>")
if grep -q __UCLIBC__ <<< "${GCC_FEATURES}"; then
echo "uClibc"
grep "#define __UCLIBC_MAJOR__" <<< "${GCC_FEATURES}"
grep "#define __UCLIBC_MINOR__" <<< "${GCC_FEATURES}"
grep "#define __UCLIBC_SUBLEVEL__" <<< "${GCC_FEATURES}"
elif grep -q __GLIBC__ <<< "${GCC_FEATURES}"; then
echo "glibc"
grep "#define __GLIBC__" <<< "${GCC_FEATURES}"
grep "#define __GLIBC_MINOR__" <<< "${GCC_FEATURES}"
else
echo "something else"
fi
(Source.)
If you're using musl, unfortunately this script will report "something else." There's no way to detect musl with a preprocessor macro, and this is intentional.
I recently tried installing an app from source (dwb on Debian Wheezy if it makes a difference). While installing, it would choke on some dependency problem, but to me it seemed I was meeting that dependency. I wasn't the only person with this problem. Which got me poking around in the project's config.mk.
In config.mk I found several blocks that looked like this:
REQPKG=foo
ifeq ($(shell pkg-config --exists $(REQPKG) && echo 1),1)
LIBS=$(REQPKG)
else
$(error Cannot find $(REQPKG))
endif
Which seems very counter intuitive to me. I searched and searched. Read the man page, consulted google. Read everything I could about pkg-config and found nothing. The man page is particularly frustrating as it simply lists '--exists' as a flag and gives no description (I guess it's as self explanatory as --help).
I began thinking that Debian's pkg-config had a bug where it returned inverse results. But, as it turns out 'pkg-config --exists' is supposed to return 0 (i.e. False) when the requested package is present.
Why is this? Wouldn't it produce cleaner code to return True/False or 1/0 indicating the presence of the required package? You could do this:
if (shell pkg-config --exists foo)
/*do things*/
else
/*throw error*/
endif
Instead of what looks to me like:
ifeq (($(not(True) && True)),True)
/*do things*/
else [...]
What am I missing about pkg-config? Does it act this way because it's a shell utility and some strange convention regarding them?
Also, why is the documentation so sparse? Am I missing a resource that would give the info I was looking for?
PS I don't have any real experience with C, so if my example code looks weird...
pkg-config --exists doesn't create any output it simply returns with an exit code of 0 for success and 1 for failure.
&& in the shell runs the right-hand side when the left-hand side returns success.
So that line is running pkg-config --exists and iff it returns true (return code of 0) it then echos a 1 as output. That 1 is then compared against the 1 in the ifeq.
And as to why you can't do something simpler here the answer is because make (when not in target rules) doesn't deal with program return codes. Specifically $(shell) pays the return code of the shell command being run no attention at all.
Personally, I'd probably have written that test as either:
ifeq ($(shell pkg-config --exists $(REQPKG); echo $?),0)
or something like
REQPKG=foo
REQPKG:=$(shell pkg-config --exists $(REQPKG) && echo '$(REQPKG)')
ifneq ($(REQPKG),)
LIBS=$(REQPKG)
else
$(error ...)
fi
Lots of UNIX commands and library functions return 0 on success. It's the "sensible default" in that world.
That's why, for example,. the prototypical "Hello, world!" in C ends with "return 0;" and not "return 1" - nonzero codes are considered erroneous. (Not that anyone is probably going to look at the return value of your HW, but still...)
Etan provides very good insight. But, there is one clarification regarding his recommendation:
ifeq ($(shell pkg-config --exists $(REQPKG); echo $?),0)
In my case, the return code is not retrievable with echo $?, so the comparison always fails. The line works directly in a terminal, but not within the shell function. I had to resort to the confusing && echo 0
Anyway, I learned a lot from his description, and thank him for that.
This seems cleaner to me:
pkg-config --exists gtk+-3.0 && echo "Installed" || echo "Not installed"
I'm on a Mac and in terminal I'm compiling my program
gcc -Wall -g -o example example.c
it compiles (there are no errors), but when I try to provide command line arguments
example 5 hello how are you
terminal responds with "-bash: example: command not found"
how am supposed to provide the arguments I want to provide after compiling?
Run it like this with path:
./example 5 hello how are you
Unless the directory where the example binary is part of the PATH variable, what you have won't work even if the binary you are running is in the current directory.
It is not a compilation issue, but an issue with your shell. The current directory is not in your PATH (look with echo $PATH and use which to find out how the shell uses it for some particular program, e.g. which gcc).
I suggest testing your program with an explicit file path for the program like
./example 5 hello how are you
You could perhaps edit your ~/.bashrc to add . at the end of your PATH. There are pro and conses (in particular some possible security issues if your current directory happens to be sometimes a "malicious" one like perhaps /tmp might be : bad guys might put there a gcc which is a symlink to /bin/rm so you need to add . at the end of your PATH if you do).
Don't forget to learn how to use a debugger (like gdb). This skill is essential when coding in C (or in C++). Perhaps consider also upgrading your gcc (Apple don"t like much its current GPLv3 license so don't distribute the recent one; try just gcc -v and notice that the latest released GCC is today 4.8.1).
./example 5 Hello how are you is the syntax you're looking for.
This article lends a good explanation as to why this is important.
Basically, when you hit Enter, the shell checks to see if the first set of characters is an absolute path. If it's not, it checks the PATH variable to find executables with the name of the command you are trying to run. If it's found, it will be run, but otherwise it will crash and burn and you will become very sad.
Now I am writing a program to call a web service. I write testMain.c. The others are generated by wsdl2h and soapcpp2.
My compiling command is like this:
gcc -Wall -g -c -L. soapC.c soapClient.c stdsoap2.c testMain.c
gcc -o testMain -L/usr/lib -lgsoap -lgsoapck -lgsoapssl soapC.o soapClient.o stdsoap2.o testMain.o
And I get these errors. Please help me.
stdsoap2.o: In function `soap_print_fault':
/test/stdsoap2.c:16279: undefined reference to `soap_check_faultsubcode'
/test/stdsoap2.c:16281: undefined reference to `soap_check_faultdetail'
stdsoap2.o: In function `soap_sprint_fault':
/test/stdsoap2.c:16341: undefined reference to `soap_check_faultdetail'
collect2: ld returned 1 exit status
Recent versions of GCC/ld/the GNU toolchain require that the object and library files be specified in a certain order, so that symbols can be found by the linker in the same order they depend on each other. This means that libraries should go to the end of the command line; your second line (when you're linking) should be
gcc -o testMain -L/usr/lib soapC.o soapClient.o stdsoap2.o testMain.o -lgsoap -lgsoapck -lgsoapssl
instead.
I search the web, and found a post which is very similar with my problem. I use this solution and have solved the problem. http://www.mail-archive.com/gsoap#yahoogroups.com/msg01022.html
You should not need to link stdsoap2.o to your project because it's already included in libgsoap (given through the gcc linker option -lgsoap). Try to exclude stdsoap2.c from your project. From the gSOAP FAQ:
I get a link error with gcc/g++ (GNU GCC). What should I do? For C
apps: use soapcpp2 option -c to generate C code, use only the
package's .c files, link with libgsoap.a (-lgsoap) or use the lib's
source stdsoap2.c (and dom.c when applicable).
I had the same problem with gsoap-2.8.16 compiled from source. (That version was shipped with CentOS 6.)
First I checked for a missing library. According to nm used on all static libraries provided by gsoap-2.8.16:
for X in /usr/local/lib/libgsoap*.a ; do echo $X; nm $X | grep soap_check_faultdetail; done`
it turned out that none of the libraries provided the missing symbols.
A brief look at the source code revealed that the expected return type of both methods soap_check_faultdetail and soap_check_faultsubcode was const char*, and that these were used to generate error messages.
It looked to me as if these are meant to be callbacks that the client must provide. Maybe their implementation is WSDL-dependent and would be supplied by the gsoap code generation utilities - that I don't know, see the answer from #ChristianAmmer above or below.
Anyway, since I knew the symbols were nowhere supplied, and that null-terminated strings were probably acceptable here, I just supplied my own no-op implementation:
// gsoap-missing-symbols.cpp
extern "C" {
const char* soap_check_faultdetail() { return 0; }
const char* soap_check_faultsubcode() { return 0; }
}
This is a brute-force solution. If you follow this solution, you should maybe check for linker warnings in the future; maybe some mechanism (eg. from the gsoap code generator) will supply conflicting implementations later during development.
For later versions of gsoap, I believe these symbols are no longer used and can be dropped (or renamed), see soap_check_faultX in https://www.genivia.com/changelog.html.
I am running a Eclipse for C/C++ using cygwin GCC. I need to get the library path of "libws2_32.a", which is in C:\cygwin\lib\w32api for me in windows. However I do not understand how this is translated into a cygwin-path.
I've tried stuff like:
/cygdrive/c/cygwin/lib/w32api
/lib/w32api
/usr/lib/w32api
Any ideas?
EDIT: update
Here's the make Eclipse log used for building, if it helps:
make all
Building target: Filesharing_core.dll
Invoking: Cygwin C Linker
gcc -L/cygdrive/c/cygwin/lib/w32api -shared -o"Filesharing_core.dll" ./src/test.o -llibws2_32.a
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -llibws2_32.a
collect2: ld returned 1 exit status
make: *** [Filesharing_core.dll] Error 1
It's not a problem with the path; it's a problem with the name of the library (the -l option).
Where you have entered libws2_32.a, instead enter ws2_32.
See the GCC manual for how the -l option works.
Generally, when asking for help with programming, don't describe, but show. Don't describe what you're doing; don't describe what you think the error is. Instead, show exactly what you're doing, show the exact code (or a cut down version that exhibits the same problem), and show the exact error message.
This way others don't have to guess as to what's wrong, and you are more likely to receive an answer right away that solves your problem.
You can use the find utility to find the file, although it may take a while.
find / -name libws2_32.a -print
Edit: Based on your edit to the question, simply move -llibws2_32.a to before ./src/test.o.
The folder C:\Opt\Cygwin\lib\w32api or whatever it is in your system is simply /lib/w32api from within Cygwin. The library you're looking for is /lib/w32api/libws2_32.a.
But I'm not sure what you're trying to achieve. I guess your Eclipse in running in Windows, and not from a Cygwin'ized version of Java? Why are you using Cygwin GCC? Do you want to compile for Cygwin? If not, MinGW or TDM-GCC would be the tool to pick.
If you do want to compile for the Cygwin environment using Eclipse (a combination I haven't tried), then user experience like the following might be helpful:
http://www.benjaminarai.com/benjamin_arai/index.php?display=/eclipsecygwingcc.php
(I simply googled: eclipse cygwin gcc)