I am trying to build the Wikiprep utility on my system. While I have built the utility, I am unable to build the Splitwiki utility. The make install instruction is
splitwiki: splitwiki.c
gcc -Wall -O2 -lz -o $# $<
I get the following error messages upon execution:
/tmp/ccXeAIs1.o: In function `split':
splitwiki.c:(.text+0xac): undefined reference to `gzputs'
splitwiki.c:(.text+0xe3): undefined reference to `gzputs'
/tmp/ccXeAIs1.o: In function `main':
splitwiki.c:(.text.startup+0xab): undefined reference to `gzopen'
splitwiki.c:(.text.startup+0x10c): undefined reference to `gzclose'
collect2: ld returned 1 exit status
make: *** [splitwiki] Error 1
I somehow have my gut saying I am missing some other packages, although I am not sure about it.
Your help is greatly appreciated. Thanks.
gzputs() is part of zlib. You're probably not linking against zlib.
At the moment I'm wondering, how you're building splitwiki. I'd have expected it being build with 'make && make install' when building wikiprep. In my case it isn't. Can you give te commandline you're using to build splitwiki and all the output?
Update: The following works for me:
$ cd tools/splitwiki
$ make splitwiki LOADLIBES=-lz
cc splitwiki.c -lz -o splitwiki # this is make output
$
Explanation: I could not find any part of the Makefile handling or any part of the README explainigg or directing how to build splitwiki. My assumption is, that one simply needs to do it manually and that's the way you tried it todo. The thing you probably have been missing was '-lz' (link against zlib). You could have used
cc splitwiki.c -lz -o splitwiki
directly. Using make is only my way to invoke the compiler :-).
Update 2: Sorry, yesterday I seem to have missed the part of the question saying "the make install instruction is". So you seem to have gotten the -lz switch. NOrmally I'd say install zlib, but I'm a bit confused that you don't get '/usr/bin/ld: cannot find -lz' as error message. Are you sure you're giving all the log output relating to the compilation of splitwiki?
Related
I am cross-compiling gpsd3.20 on my Ubuntu 16.04 for the ARM architecture. As you may know, gpsd uses Sconsctruct to compile the source codes. During my cross-compilation, the moment when it needs to create the libgps.so it shows an error unrecognized option '-Wl, -Bsymbolic'.
Before posting the question here, I have tried t check my toolchain binaries and I found out that if I run this line manually:
sudo ./arm-v7a-linux-gnueabihf-ld -o test/gpsd-3.20/libgps.so.25.0.0 -pthread -shared -Wl,-Bsymbolic-functions -Wl,-soname=libgps.so.25 test/gpsd-3.20/os_compat.os test/gpsd-3.20/rtcm2_json.os test/rtcm3_json.os test/gpsd-3.20/shared_json.os test/gpsd-3.20/timespec_str.os test/gpsd-3.20/libgpsmm.os -L. -lrt -lm -lrt
The above commands print out the exact error as I mentioned previously. However, if I run the exact command replacing ld with gcc, then there is no any errors.
sudo ./arm-v7a-linux-gnueabihf-gcc -o test/gpsd-3.20/libgps.so.25.0.0 -pthread -shared -Wl,-Bsymbolic-functions -Wl,-soname=libgps.so.25 test/gpsd-3.20/os_compat.os test/gpsd-3.20/rtcm2_json.os test/rtcm3_json.os test/gpsd-3.20/shared_json.os test/gpsd-3.20/timespec_str.os test/gpsd-3.20/libgpsmm.os -L. -lrt -lm -lrt
Upon checking the arm-v7a-linux-gnueabihf-gcc --help, I found out that, gcc support -Wloptions whereas in the arm-v7a-linux-gnueabihf-ld it doesn't support the -Wl options. So now I am not sure how to change the SConstruct file so that it doesn't execute ld instead I want it to execute gcc especially for the libgps.so part.
(can't comment), so as answer: have you tried to set the env.-var.:
export LD=arm-v7a-linux-gnuabihf-gcc
Gcc takes -Wl,XXX and passes XXX to the linker.
I think you've got two combining problems here, though there's some guessing involved without looking into the build itself. First, scons shouldn't be adding the flag when building a library (https://github.com/SCons/scons/issues/3248 - fixed but, I believe, not part of a release). Second, "linking" should probably be done using gcc. If you call gcc to link, it still calls the linker behind the scenes - after dealing with options that are intended for gcc, which -Wl,-Bsymbolic is, it means pass -Bsymbolic on to the linking phase (indicated by -Wl, the 'l' meaning linker). So I'm supposing that the way you've told scons about the cross toolchain isn't quite right either, if it's calling ld directly you're probably going to have other issues as well.
I am trying to test a C++ library and have to do a little more than the AC_SEARCH_LIBS or AC_CHECK_LIB. However, my linker is picky about the order of the options (g++ version 5.4.0).
My configure.ac contains the following code:
AC_LINK_IFELSE(
[AC_LANG_PROGRAM([#include <api/BamReader.h>], [BamTools::BamReader dummy])],
[TEST_LIBS=="$TEST_LIBS -lbamtools"] [HAVE_BAMTOOLS=1],
[AC_MSG_WARN([libbamtools is not installed])])
I know that the Bamtools are install on my system. This will generate an negative result:
checking api/BamReader.h usability... yes
checking api/BamReader.h presence... no
configure: WARNING: api/BamReader.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: api/BamReader.h: proceeding with the compiler's result
checking for api/BamReader.h... yes
configure: WARNING: libbamtools is not installed <-- this line
After some investigation, it appears to be the order of the linker option.
The conftest.cpp file looks like the following:
#include <api/BamReader.h>
int main () {
BamTools::BamReader dummy;
return 0;
}
The autoconf macro is calling
g++ -o conftest -g -O2 -I/usr/local/include/bamtools -L/usr/local/lib/bamtools -lbamtools conftest.cpp/tmp/ccZiV1J9.o: In function `main':
/home/kzhou/coding/tmp/conftest.cpp:24: undefined reference to `BamTools::BamReader::BamReader()'
/home/kzhou/coding/tmp/conftest.cpp:24: undefined reference to `BamTools::BamReader::~BamReader()'
collect2: error: ld returned 1 exit status
If yo switch the order by putting the -lbamtools to the end, then the linker is happy:
g++ -o conftest -g -O2 -I/usr/local/include/bamtools -L/usr/local/lib/bamtools conftest.cpp -lbamtools
I wonder the AC_LANG_PROGRAM needs to be updated? Please comment. So far I have not found a good solution for this problem.
Please reference:
https://nerdland.net/2009/07/detecting-c-libraries-with-autotools/
This looks like you are passing the library in the wrong variable; if you were passing the library in LIBS it would be in the right position because autoconf does the right thing.
Now, the code you pasted has a syntax error too (using == which is a comparison instead of = which is an assignment), and a logical one since TEST_LIBS was a variable used by the specific post you reference. So that is not what is setting -lbamtools in any of the orders.
save_LIBS=$LIBS
LIBS="$LIBS -lbamtools"
AC_LINK_IFELSE(
[AC_LANG_PROGRAM([#include <api/BamReader.h>], [BamTools::BamReader dummy])],
[save_LIBS="$LIBS"; HAVE_BAMTOOLS=1],
[AC_MSG_WARN([libbamtools is not installed])])
LIBS=$save_LIBS
this should do what you're looking for, although it's still a bit more complicated than it could be. You could use AC_CHECK_TYPE to just check if BamTools::BamReader is defined.
I'm trying to test out a new dev environment and I am having some problems referencing some of the required Qt libraries.
First I ran this:
$ g++ HelloWorld.C -o HelloWorld -I /usr/local/Trolltech/Qt-4.5.1/include/QtCore/ -I /usr/local/Trolltech/Qt-4.5.1/include/
and got this error:
/tmp/ccmsm4kZ.o: In function `QString::QString(char const*)':
HelloWorld.C:(.text._ZN7QStringC2EPKc[_ZN7QStringC5EPKc]+0x1d): undefined reference to `QString::fromAscii_helper(char const*, int)'
/tmp/ccmsm4kZ.o: In function `QString::~QString()':
HelloWorld.C:(.text._ZN7QStringD2Ev[_ZN7QStringD5Ev]+0x2d): undefined reference to `QString::free(QString::Data*)'
collect2: ld returned 1 exit status
So then I added reference to the QtCore library via:
$ g++ HelloWorld.C -o HelloWorld -I /usr/local/Trolltech/Qt-4.5.1/include/QtCore/ -I /usr/local/Trolltech/Qt-4.5.1/include/ -L /usr/local/Trolltech/Qt-4.5.1/lib -lQtCore
which removed the compile errors, however when I try to run the program I get this error:
./HelloWorld: error while loading shared libraries: libQtCore.so.4: cannot open shared object file: No such file or directory
I wasn't able to find a solution for this problem via google. Anyone have advice?
That error indicates that while the linker can find the library at compilation, it can't find it during runtime.
You should update your LD_LIBRARY_PATH to include that location like this:
In ~.bashrc probably somewhere near the bottom:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/Trolltech/Qt-4.5.1/lib
Alternatively, if you want to make this persistent throughout your system (and have root access), you can make an entry in /etc/ld.so.conf.d (on RedHat, I'm not sure about the other distributions)
touch /etc/ld.so.conf.d/qt.conf
Add the path to this file, and then update your runtime via /sbin/ldconfig
Gurus!
I am using Ubuntu 13.10 64-bit to compile latest Google RE2 library, but 'make testinstall' failed to compile, here is the log:
kevin#ubuntu:~/re2$ make testinstall
cp testinstall.cc obj
(cd obj && g++ -I/usr/local/include -L/usr/local/lib testinstall.cc -lre2 -pthread -o testinstall)
/tmp/ccSsaSXS.o: In function main':
testinstall.cc:(.text+0xce): undefined reference tore2::FilteredRE2::FirstMatch(re2::StringPiece const&, std::vector > const&) const'
/usr/local/lib/libre2.so: undefined reference to pthread_rwlock_rdlock'
/usr/local/lib/libre2.so: undefined reference topthread_rwlock_wrlock'
/usr/local/lib/libre2.so: undefined reference to pthread_rwlock_destroy'
/usr/local/lib/libre2.so: undefined reference topthread_rwlock_init'
/usr/local/lib/libre2.so: undefined reference to `pthread_rwlock_unlock'
collect2: error: ld returned 1 exit status
make: * [testinstall] Error 1
I tried to replace -pthread with -lpthread, still failed, then I dumped libre2.so and found that pthread_xxx is in it.
Here is the issue tracking in RE2 forum: https://code.google.com/p/re2/issues/detail?id=100
Anyone here have ever complied RE2 successfully ? Thank you!
See this comment:
Adding -pthread to LDFLAGS seems to fix make test (all tests are
passing), but not make testinstall.
That will get you to the next error
Depending on what you build it for 'make testinstall' might not be necessary.
I just needed to get python re2 port working, and this can be installed after running make install.
I encounter this problem before. Modify the makefile and use -lpthread instead of -pthread.
So I tried looking for the lines in testinstall.cc that were causing the symbol errors and I found out that the only line was on line 18:
18 - f.firstMatch(:abbccc:, ids);
I commented this line out (so that the FullMatch function below is still called) and just ran g++ testinstall.cc -lre2 -pthread -o testinstall (basically what the Makefile does) and I was able to get a binary successfully. Although this might not really solve the problem, its good to know that we can still use the RE2::Fullmatch and partial match functions
If I were to guess, maybe there is a dependency somewhere inside the filtered_re2 module?
I had the same problem. But if you compile with -static everything goes well.
nm -C shows that the "missing" symbol exists in both .a and .so files.
I used the MinGW installation at http://nuwen.net/mingw.html
I ran the second.cpp test found at:
http://tabreziqbal.wordpress.com/2006/03/16/how-to-test-c-boost-installation/
(I used the correct commands to run from the comments, which was
g++ -o second second.cpp -lboost_filesystem)
I get the following error:
C:\Users\user\Projects\Programming\C++\boostTest2>g++ -o second second.cpp -lboost_filesystem
C:\Users\user\AppData\Local\Temp\ccDlbKGy.o:second.cpp:(.text+0x102): undefined reference to boost::system::generic_cat
egory()'
C:\Users\user\AppData\Local\Temp\ccDlbKGy.o:second.cpp:(.text+0x10c): undefined reference toboost::system::generic_cat
egory()'
C:\Users\user\AppData\Local\Temp\ccDlbKGy.o:second.cpp:(.text+0x116): undefined reference to boost::system::system_cate
gory()'
C:\MinGW\bin/ld.exe: C:\Users\user\AppData\Local\Temp\ccDlbKGy.o: bad reloc address 0xe in section.text$_ZN5boost6syst
em14error_categoryD1Ev[__ZN5boost6system14error_categoryD1Ev]'
C:\MinGW\bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status
I know there's an installation test feature of boost that I found on
http://gcc.gnu.org/testing/testing-boost.html
but those files aren't included with the distribution from nuwen.net (so I'd have to do it myself).
And help is appreciated - I figure I'm just screwing up something minor (I hope anyway).
Thanks all!
It's not correct command, you should link boost::system too (errors are undefined references to boost::system::system_category).
Correct command will be g++ -o second second.cpp -lboost_system -lboost_filesystem