I dont understand why g++ cannot find getnameinfo in ws2_32, nm shows that it is there. Here is the output:
$ I:/Programs/MinGW/msys/1.0/bin/sh.exe ../libtool --tag=CXX --mode=link g++
-g -O2 -no-undefined -version-info 16:0:0 -o libetpan.la -rpath /i/Programs/M
inGW/lib dummy.lo versioninfo.lo data-types/libdata-types.la low-level/liblow-l
evel.la driver/libdriver.la main/libmain.la engine/libengine.la windows/libarch
.la -L/i/Programs/MinGW/lib -lws2_32 -liconv
libtool: link: rm -fr .libs/libetpan.dll.a
libtool: link: g++ -shared -nostdlib i:/programs/mingw/bin/../lib/gcc/mingw32/4.
7.0/../../../dllcrt2.o i:/programs/mingw/bin/../lib/gcc/mingw32/4.7.0/crtbegin.o
.libs/dummy.o .libs/versioninfo.o -Wl,--whole-archive data-types/.libs/libdat
a-types.a low-level/.libs/liblow-level.a driver/.libs/libdriver.a main/.libs/lib
main.a engine/.libs/libengine.a windows/.libs/libarch.a -Wl,--no-whole-archive
-lws2_32 -lws2_32 -lws2_32 -lws2_32 -lws2_32 -lws2_32 -L/i/Programs/MinGW/lib -l
ws2_32 /mingw/lib/libiconv.dll.a -Li:/programs/mingw/bin/../lib/gcc/mingw32/4.7.
0 -Li:/programs/mingw/bin/../lib/gcc -Li:/programs/mingw/bin/../lib/gcc/mingw32/
4.7.0/../../../../mingw32/lib -Li:/programs/mingw/bin/../lib/gcc/mingw32/4.7.0/.
./../.. -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi3
2 -lshell32 -luser32 -lws2_32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmi
ngwex -lmsvcrt i:/programs/mingw/bin/../lib/gcc/mingw32/4.7.0/crtend.o -O2 -p
thread -o .libs/libetpan-16.dll -Wl,--enable-auto-image-base -Xlinker --out-impl
ib -Xlinker .libs/libetpan.dll.a
Creating library file: .libs/libetpan.dll.a
Warning: resolving _closesocket by linking to _closesocket#4
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
low-level/.libs/liblow-level.a(mailsmtp.o): In function `get_hostname':
c:\libetpan-00c7589\src\low-level\smtp/mailsmtp.c:266: undefined reference to `_
getnameinfo'
collect2.exe: error: ld returned 1 exit status
$ nm /i/Programs/MinGW/lib/libws2_32.a | grep getnameinfo
00000000 I __imp__getnameinfo#28
00000000 T _getnameinfo#28
I needed to #define _WIN32_WINNT 0x0501
Related
I want to statically link a library say libcurl. As both static and shared libraries are in same folder, I am using -Wl,-Bstatic to let the linker know to use static library.
g++ -o prog prog.o -Wl,-Bstatic -lcurl.
But above command is giving error:
/usr/bin/ld: cannot find -lgcc_s
If I exclude -Wl,-Bstatic, it works fine, but It will use shared library which I dont want.
What is going wrong?
When you use the g++ front-end to perform your linkage, like:
g++ -o prog prog.o -Wl,-Bstatic -lcurl
g++ invokes the linker passing it your linkage options and also silently
adding to the linker commandline a large number of boiler-plate options that
are invariant for C++ linkage.
For example, your C++ program very probably will need to link the standard C++ library,
libstdc++, but your g++ command doesn't mention it. It certainly also needs the standard C library,
but it isn't mentioned either. g++ automatically adds linkage options to link these and
other libraries.
You can see all the boilerplate that g++ adds to your linkage by running it in
verbose mode. You will see the like of:
$ g++ -v -o prog prog.o -Wl,-Bstatic -lcurl
...
...
COLLECT_GCC_OPTIONS='-v' '-o' 'prog' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so \
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper \
-plugin-opt=-fresolution=/tmp/cckwrJp6.res -plugin-opt=-pass-through=-lgcc_s \
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc \
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc \
--sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu \
--as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro \
-o prog /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o \
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o \
/usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o \
-L/usr/lib/gcc/x86_64-linux-gnu/7 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu \
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu \
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib \
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. prog.o \
-Bstatic -lcurl -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc \
/usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o \
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
/usr/bin/x86_64-linux-gnu-ld: cannot find -lgcc_s
/usr/bin/x86_64-linux-gnu-ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
Note in particular your -Bstatic option and the following linkage options:
-Bstatic -lcurl -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc \
/usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o \
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
which include your -lcurl and also the default system libraries:
-lcurl -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
Then see the documentation of the -Bstatic linker option:
-Bstatic
...
Do not link against shared libraries. This is only meaningful on platforms for which shared libraries are supported.
The different variants of this option are for compatibility with various systems.
You may use this option multiple times on the command line: it affects library searching for -l options which follow it.
This option also implies --unresolved-symbols=report-all. This option can be used with -shared.
Doing so means that a shared library is being created but that all of the library’s external
references must be resolved by pulling in entries from static libraries.
[my emphasis]
So, your -Bstatic option directs the linker to link static versions of:
-lcurl -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
It finds the static libcurl.a that you have installed. It fails to find a
static library for -lgcc_s because there isn't any libgcc_s.a installed on
your system. You just have dynamic versions of this and other basic system libraries,
which is pretty normal.
If you want the linker to link static libraries only for the -l options that you
specify, then you must turn on -Bstatic before your -l options and turn it off
after them, -Bdynamic, even if this makes -Bdynamic the last thing on your commandline.
Because g++ (or any other GCC front-end, gcc, gfortran...) is going to add -l
options to your commandline behind the scenes. Link like:
g++ -o prog prog.o -Wl,-Bstatic -lcurl -Wl,-Bdynamic
to fix this particular linkage error.
i'm trying to build clang with mingw-w64 on windows (10), so i followed this tutorial : https://here-be-braces.com/blog/llvm-clang-on-windows-mingw-revisited
but cmake don't recognise gcc as an C++11 compiler. I run cmake with this command :
cmake C:\llvm -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_TOOLS=ON -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_BUILD_TESTS=OFF -DLLVM_INCLUDE_TESTS=OFF -DLLVM_ENABLE_EH=ON -DLLVM_ENABLE_RTTI=ON -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_CXX_FLAGS="-IC:/mingw64/x86_64-w64-mingw32/include" -DGCC_INSTALL_PREFIX=%syspath% -DCMAKE_INSTALL_PREFIX=%syspath% -DCMAKE_EXE_LINKER_FLAGS="-lmingw32 -static-libgcc -static-libstdc++ -static -lstdc++ -lm -lpthread -lgcc -lmsvcrt -lmoldname -lgcc_eh -lkernel32 -luser32 -ladvapi32 -liconv -lmingwex" -DBUILD_SHARED_LIBS=OFF -DLLVM_PARALLEL_COMPILE_JOBS=2 -DLLVM_PARALLEL_LINK_JOBS=2 -DCMAKE_INCLUDE_PATH="C:/mingw64/x86_64-w64-mingw32/include" -DGCC_INSTALL_PREFIX="C:/mingw64" -DCMAKE_LIBRARY_PATH="C:/mingw64/x86_64-w64-mingw32/lib"
I obtened the list of librairies with "gcc -v test.c -Wl,--verbose", test.c is just an classic hello world. But with the libmingw32, I get this error :
cmd.exe /C "cd . && C:\mingw64\bin\gcc.exe -lmingw32 -static-libgcc
-static-libstdc++ -static -lstdc++ -lm -lpthread -lgcc -lmsvcrt -lmoldname
-lgcc_eh -lkernel32 -luser32 -ladvapi32 -liconv -lmingwex
CMakeFiles/cmTC_3b639.dir/testCCompiler.c.obj -o cmTC_3b639.exe
-Wl,--out-implib,libcmTC_3b639.dll.a
-Wl,--major-image-version,0,--minor-image-version,0 -lkernel32 -luser32
-lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32
-ladvapi32 && cd ."
CMakeFiles/cmTC_3b639.dir/testCCompiler.c.obj:testCCompiler.c:(.text+0x0):
multiple definition of `main'
C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/lib/../lib\libmingw32.a(lib64_libmingw32_a-crt0_c.o):crt0_c.c:(.text.startup+0x0):
first defined here
C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/lib/../lib\libmingw32.a(lib64_libmingw32_a-crt0_c.o):crt0_c.c:(.text.startup+0x2e):
undefined reference to `WinMain'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
Without it, i get further, but i get this : http://pastebin.com/zeMViHzA
CMake Error at projects/libcxx/CMakeLists.txt:423 (message):
C++11 or greater is required but the compiler does not support c++11
How can i get rid of the "WinMain undefined reference" for the cmake tests ?
edit : the gcc version : 6.2.0
I couldn't find a direct answer on Google, and since I haven't done stuff on Linux for a long time hoped to find help here. I am getting a linking error on Ubuntu when building a shared object. The linker tells me I should recompile with -fPIC even though I have set -fPIC for all source files. The output of make:
mkdir -p ../_Bin/Debug/HttpClientApi
g++ -fPIC -pedantic -Wall -Wextra -std=c++11 -c CentralServerClient.cpp -o ../_Bin/Debug/HttpClientApi/CentralServerClient.o
CentralServerClient.cpp:4:80: warning: unused parameter ‘pEventListener’ [-Wunused-parameter]
void CCentralServerClient::AddEventListener(ICentralServerClientEventListener* pEventListener)
^
CentralServerClient.cpp:29:83: warning: unused parameter ‘pEventListener’ [-Wunused-parameter]
void CCentralServerClient::RemoveEventListener(ICentralServerClientEventListener* pEventListener)
^
g++ -fPIC -pedantic -Wall -Wextra -std=c++11 -c HttpRequest.cpp -o ../_Bin/Debug/HttpClientApi/HttpRequest.o
g++ -fPIC -pedantic -Wall -Wextra -std=c++11 -c HttpResponse.cpp -o ../_Bin/Debug/HttpClientApi/HttpResponse.o
g++ -fPIC -pedantic -Wall -Wextra -std=c++11 -c IOService.cpp -o ../_Bin/Debug/HttpClientApi/IOService.o
g++ -Wl,-shared -Wl,-v -Wl,-g -o ../_Bin/Debug/HttpClientApi.so ../_Bin/Debug/HttpClientApi/CentralServerClient.o ../_Bin/Debug/HttpClientApi/HttpRequest.o ../_Bin/Debug/HttpClientApi/HttpResponse.o ../_Bin/Debug/HttpClientApi/IOService.o
collect2 version 4.9.2
/usr/bin/ld -plugin /usr/lib/gcc/x86_64-linux-gnu/4.9/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper -plugin-opt=-fresolution=/tmp/ccZ9RMHe.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro -o ../_Bin/Debug/HttpClientApi.so /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.9/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.9 -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. -shared -v -g ../_Bin/Debug/HttpClientApi/CentralServerClient.o ../_Bin/Debug/HttpClientApi/HttpRequest.o ../_Bin/Debug/HttpClientApi/HttpResponse.o ../_Bin/Debug/HttpClientApi/IOService.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/4.9/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o
GNU ld (GNU Binutils for Ubuntu) 2.25
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o: relocation R_X86_64_32S against `__libc_csu_fini' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:15: recipe for target '../_Bin/Debug/HttpClientApi.so' failed
make: *** [../_Bin/Debug/HttpClientApi.so] Error 1
gcc is gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13)
Any help is appreciated.
Instead of giving g++ -Wl,-shared you should give it -shared. The reason is that g++ need to know which crt1.o to use - one suitable for shared libraries (compiled with -fPIC, scrt1.o) or one which is not suitable.
When you give -shared to g++ it knows to use scrt1.o. But when you pass `-Wl,-shared', g++ doesn't know that you are building shared library - it 'thinks', you are building a normal executable (linker does know what is happening) and asks linker to link with crt1.o. Linker refuses and you have an error.
I just installed manually apr and apr_util so i can install activemq c++ library.
When i try to make the cpp library i get the following error:
**
libtool: link: g++ -ansi -pedantic -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/usr/local/apr/include/apr-1 -I/usr/local/apr/include/apr-1 -I/usr/kerberos/include -W -Wall -Wextra -Wconversion -fPIC -fstrict-aliasing -Wstrict-aliasing=2 -Wno-long-long -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/usr/local/apr/include/apr-1 -I/usr/local/apr/include/apr-1 -I/usr/kerberos/include -Wno-non-virtual-dtor -Wno-unused-parameter -Wno-uninitialized -I./../main -g -O2 -pthread -o .libs/example example-main.o ../main/.libs/libactivemq-cpp.so -lexpat -L/usr/kerberos/lib64 /usr/local/apr/lib/libaprutil-1.so /usr/local/apr/lib/libapr-1.so -luuid -lrt -lcrypt /usr/local/apr/lib/libexpat.so -lssl -lcrypto -ldl -lz -lpthread -pthread -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/local/apr/lib
/usr/bin/ld: cannot find -lexpat
collect2: ld returned 1 exit status
**
and expat is within apr-util and not being linked. how can i update the ld path so that make or environment will find it?
or in short: how can i resolve this?
Usually you'll need to manually specify the library path using -L option.
It would look like ld filename -Lpath -llibname in a single ld operation. Or in this case you may need to add the paths of your library(apr-util here) to the constant of library paths in a Makefile.
I have a project that is a library that links against libresolv,
It works fine on recent distros: Ubuntu 10.x Fedora 13, Mandriva
2010.1 but on Centos 5.x I get the following errors
glibc installed is: glibc-2.5-18.el5_1.1
g++ -DHAVE_CONFIG_H -I. -I./include -I/usr/include/postgresql -O3
-ansi -Wall -Wno-deprecated -D_FORTIFY_SOURCE=0 -MT testUpLog.o -MD
-MP -MF .deps/testUpLog.Tpo -c -o testUpLog.o testUpLog.cc
mv -f .deps/testUpLog.Tpo .deps/testUpLog.Po
/bin/sh ./libtool --tag=CXX --mode=link g++ -O3 -ansi -Wall
-Wno-deprecated -D_FORTIFY_SOURCE=0 -L/usr/lib64 -L/lib64
-L/usr/lib64/mysql -o testUpLog testUpLog.o libUpTools.la -lpq
-lmysqlclient -lssl -lpthread
libtool: link: g++ -O3 -ansi -Wall -Wno-deprecated -D_FORTIFY_SOURCE=0
-o .libs/testUpLog testUpLog.o -L/usr/lib64 -L/lib64
-L/usr/lib64/mysql ./.libs/libUpTools.so -lpq -lmysqlclient -lssl
-lpthread
./.libs/libUpTools.so: undefined reference to `__ns_name_uncompress'
./.libs/libUpTools.so: undefined reference to `__ns_initparse'
./.libs/libUpTools.so: undefined reference to `__ns_parserr'
collect2: ld returned 1 exit status
make[1]: *** [testUpLog] Error 1
make[1]: Leaving directory `/tmp/UpTools-8.5.3'
make: *** [check-am] Error 2
library.la file contains:
dlname='libUpTools.so.0'
library_names='libUpTools.so.0.0.0 libUpTools.so.0 libUpTools.so'
old_library='libUpTools.a'
inherited_linker_flags=''
dependency_libs=' -L/usr/lib64 -L/lib64 -L/usr/lib64/mysql -lpq
-lmysqlclient -lssl -lpthread'
weak_library_names=''
current=0
age=0
revision=0
installed=no
shouldnotlink=no
dlopen=''
dlpreopen=''
libdir='/usr/lib'
You can read configure.ac on
http://pastebin.com/hs5q21Rq
Thanks in advance
If libUpTools uses functions lib libresolv, you need to say so:
libUpTools_la_LIBADD = -lresolv (of course -lresolv may be replaced by variables determined by configure etc.)
That way, -lresolv will end up in the .la file and also in the .so file (if you chose to build it) that you can run ldd on for verification.