I'm cross compiling on Windows 7 and I use this compiler:
gcc-linaro-arm-linux-gnueabihf-4.7-2013.03\bin\arm-linux-gnueabihf-g++.exe
I want to use libcurl for some HTTP requests but when I link using -libcurl I get the infamous message that the linker couldn't find that library. I tried searching on the internet for the correct library for this architecture (ARMHF) but I can't find anything. Or maybe I did find it but I'm doing things wrong? My linking call is long but here it is:
This is the one that works, if I add -libcurl or anything related it breaks...
C:\vde\toolchains\windows\vos2\gcc-linaro-arm-linux-gnueabihf-4.7-2013.03\bin\arm-linux-gnueabihf-g++.exe -o out\RefApp -Wl,-rpath=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\lib -Wl,-r
path=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\local\lib -Wl,-rpath=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\lib -Wl,-rpath=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-3101
0800\vos2\usr\local\lib\svcmgr C:\desarrollo\corvet\out\corvet.a -LC:\desarrollo\RefApp\lib -LC:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\local\lib -LC:\vde\SDKs\vos2\vos2-sdk-winx86-re
lease-31010800\vos2\lib -LC:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\local\lib\svcmgr -LC:\vde\ADKs\adk-full-4.6.5-610\vos2\lib -L -LC:\desarrollo\corvet\out -lrt -llog -lvfiguiprt -l
vfiipc -lTLV_Util -lpthread -lvfiplatforminfo -lsvc_utility -lvfibuzzer -lsvc_powermngt -lsvc_led -lvfisysinfo -lvfisysbar -lsqlite -lexpat -linf -lcom -levt -ltecclient -lmsrclient -lEMV_CT_Link -lEM
V_CT_Client -lEMV_CTLS_Link -lEMV_CTLS_Client -lNFC_Framework -lNFC_Client -lsvc_tms -lUtils -lseccmd-static -lsvc_sound -lccp -lcrypto -lsec -lseccmd-static -lsecins -lvfisvc -lvfisyspm -lvfimac -lvf
isec -lAdkCapX
I also tried downloading some libcurl libraries I found on debian page and that were supposedly for ARMHF, put them in some folder and used -L(routetofolder) but that didn't work either.
Hope you guys can help me out.
Thanks!
Well, libcurl is there in what you get from the vendor (if you look at /usr/lib you will find it there). It's a problem with your linking.
You might want to try looking at how dynamic libraries dependencies are resolved at linking and later at runtime on linux systems. It will also help you understand what may be happening on vos2 platform when you will try using your own dynamic libraries that may have conflicting names and linker can resolve them to something existing on the same device but at a location that you might not have permissions to read, because it belongs to different usrXX or sysXX.
Reading /etc/ld.so.conf from the device will help you understand the locations and search order done by dynamic linker. You can get the file from the device or simply find it in OS.rfsbundle (look in skeletonfs) and set your linking options right. I think it's not normally distributed with sysroot by the vendor but you can manually add it.
Related
(I saw answers of every single StOF questions regarding this - none fully helped. I'm very frustrated after trying so hard for 3 days & nights.)
libcurl.a is statically linked with:
OpenSSL 1.1.1k [64bit/32bit]
brotli 1.0.9 [64bit/32bit]
libgsasl 1.10.0 [64bit/32bit]
libidn2 2.3.1 [64bit/32bit]
libssh2 1.9.0 [64bit/32bit]
nghttp2 1.43.0 [64bit/32bit]
zlib 1.2.11 [64bit/32bit]
zstd 1.5.0 [64bit/32bit]
Case 1 - as if curl isn't statically linked
x86_64-w64-mingw32-gcc-10.2.0.exe -o main.exe main.c "C:\curl-7.77.0-win64-mingw\lib\libcurl.a" -DCURL_STATICLIB
Throws unending lines of error, as if libcurl isn't statically linked with its dependencies*:
...\lib\libcurl.a(http2.o):(.text+0x7f): undefined reference to `nghttp2_version'
...\lib\libcurl.a(http2.o):(.text+0x297): undefined reference to `nghttp2_submit_rst_stream'
... (then the errors include many more undefined reference to symbols from nghttp2, ssl, crypt, ssh, gsasl)
The best way to use libcurl is to get the necessary flags via pkg-config. In MSYS2 this works quite well. Otherwise you may need to point the environment variable PKG_CONFIG_PATH to the location of libcurl.pc.
On my system
pkg-config --define-prefix --static --libs libcurl
returns:
-LD:/Prog/winlibs64-11.1.0/custombuilt/lib -lcurl -lidn2 -lrtmp -lssh2 -lnettle
-lgnutls -ladvapi32 -lcrypt32 -lgss -lwldap32 -lzstd -lz -lws2_32 -lrtmp
Note that with MinGW the order of the libraries is also important. The library providing a symbol should be mention on the linker command line after the object that refers to that symbol.
Finally you need to make sure that each library you include was in fact built and used statically. With that I mean no stuff like __declspec(dllexport) may be used when building it, and no __declspec(dllimport) may be used when compiling anything that depends on it. For some libraries this may require specific defines before including the library's header(s).
Specifically for libcurl and nghttp2 I find that it helps to add the following at the top of lib/http2.c and lib/http.c when building libcurl:
#if defined(BUILDING_LIBCURL) && !defined(DLL_EXPORT)
#define NGHTTP2_STATICLIB
#endif
This will define NGHTTP2_STATICLIB when building static libcurl.
I have reported this as a bug at: https://github.com/curl/curl/issues/7353
It is so enormously saddening to see how many people have struggled and are still struggling to statically link libcurl to their program. So much so that a very active Curl maintainer said: "building static is a roller coaster left for the users to deal with on their own as its such a never-ending race for us to try to support."
Since linker is saying undefined references, then libcurl.a must be:
not statically linked
Or, you've got the sequence of libraries unarranged. Linker is sensitive to sequence. Example: If libbrotlidec-static.a needs a function/symbol which is inside libbrotlienc-static.a, then libbrotlienc-static.a must be mentioned before libbrotlidec-static.a
A static library is an archive .a of object .obj files. And they're not statically linked in themselves. That's why, to link some-static-library.a to a program, you need to collect and manually mention every.a single.a static.a library.a that are dependencies of some-static-library.a.
In my Chat#Terminal:~$ project, I should have a make.bat file which shows how to statically link libcurl to a program using gcc or mingw. And finally static-compile the whole program, and ship without any runtime dependency!
On a side-note, curl's precompiled-binary website says: Curl_x.x.x is statically linked with: [list of libraries you provided]. Break your misconception that, the statement made at the website means: Curl.exe is statically linked with the libs, not libcurl.
I'm trying to write a simple syntax checker for C code using the frontend available in libclang. Due to deployment concerns, I need to be able to statically link all the libraries in libclang, and not pass around the .so file that has all the libraries.
I'm building clang/llvm from source, and in llvm/Release+Asserts/lib I have a bunch of .a files that I think I should be able to use, but it never seems to work (the linker spews out thousands of errors about missing symbols). However, when I compile it using the libclang.so also present in that directory as follows:
clang main.c -o bin/dlc -I../llvm/tools/clang/include -L../llvm/Release+Asserts/lib/ -lclang
Everything seems to work well.
What is the minimum set of .a files I need to include to make this work? I've tried including absolutely all of the .a files in the build output directory, with them provided to clang/gcc in different orders, without any success. I only need the functions mentioned in libclang's Index.h, but there don't seem to be any resources or documentation on what the various libclang*.a files are for. It would be very helpful to know which files libclang.so pulls in.
The following is supposed to work, as long the whole project has all static libraries (I counted 116 in my Release/lib directory).
clang main.c -o bin/dlc -I../llvm/tools/clang/include ../llvm/Release/lib/*.a
[edit: clang main.c -o bin/dlc -I../llvm/tools/clang/include ../llvm/Release/lib/libclang.a ../llvm/Release/lib/*.a]
Note that the output binary is not static, so you don't need any -static flag for gcc or ld, if you're using this syntax.
If that doesn't work you might need to list the libraries in order: if some library requires a function available in another library, then it may be necessary to list it first in the command line. See comments about link order at:
http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Link-Options.html#Link-Options
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)
I am trying to port NewLib for my OS (I am following this tutorial: http://wiki.osdev.org/Porting_Newlib), and I have some questions.
Once LibGloss is done and compiled, when exactly will I have to use the libnosys.a that have been created? Is it when I will compile my main.c?
mipsel-uknown-elf-gcc main.c -Llibnosys.a`
My crt0.c is done. And I have to "link it as the first object". How can I do that? Is it something like this?
mipsel-uknown-elf-ld crt0.o main.o
Thanks for your answers!
Linking as the first object might work just fine like you are displaying, but the docs does mention using a linker script and adding crt0.o as STARTUP() -- I'm not too familiar with linker scripts, but you can find the default linker script and possibly create it/adjust it:
Syntax of linking script: http://wiki.osdev.org/Linker_Scripts
http://sourceware.org/binutils/docs-2.19/ld/Scripts.html#Scripts
The linker always uses a linker script. If you do not supply one yourself, the linker
will use a default script that is compiled into the linker executable. You can use the
`--verbose' command line option to display the default linker script. Certain command
line options, such as `-r' or `-N', will affect the default linker script.
The same can probably be done with other system libraries that always have to be part of the linking.
It's fine to add all on the command line, but a bit tedious in the end.
Are you getting any errors or wrong results since you are asking or what?
Using a vendor provided cross-compiling toolchain (apparently an OpenEmbedded derivative), I'm unable to embed the absolute path to third-party (open source, compiled in house)libraries. With the following gcc command line:
arm-linux-gcc test_connect_send.o gprs_connect.o \
/package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libgprs_stuff.so \
/package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libpower_supply_stuff.so \
/package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libgsm_stuff.so \
/package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libtcp_stuff.so \
/package/host/aspl.es/vortex-1.1.0/lib/libvortex-1.1.so \
/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0 -o test_connect_send
objdump says:
Dynamic Section:
NEEDED /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libgprs_stuff.so
NEEDED /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libpower_supply_stuff.so
NEEDED /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libgsm_stuff.so
NEEDED /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libtcp_stuff.so
NEEDED libvortex-1.1.so.0
NEEDED libaxl.so.0
NEEDED libgcc_s.so.1
NEEDED libc.so.6
Notice how my vendor's libraries do have their full path, while aspl's don't. Also, notice how the name embedded is different from the one I specified on the command line. I'd like to know why (who is messing with my paths), and how to solve it.
p.s.: I know about RPATH, that's not the answer I'm looking for
My guess would be that the vendor supplied libs set the SONAME to the full installed path.
arm-linux-gcc -print-file-name does not show anything suprising:
arm-linux-gcc -print-file-name=/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0.0.0
/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0.0.0
arm-linux-gcc -print-file-name=/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0.0
/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0.0
arm-linux-gcc -print-file-name=/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0
/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0
arm-linux-gcc -print-file-name=/package/host/aspl.es/axl-0.5.6/lib/libaxl.so
/package/host/aspl.es/axl-0.5.6/lib/libaxl.so
The resulting binary does not run without LD_LIBRARY_PATH defined, nor does it have a DT_RPATH (although that might certainly help, suggestions?)
I don't want to rely on /etc/ld.so.conf being properly set, and thus I want absolute paths everywhere.
Note that suggestions might well point to the compilation of the third-party libraries, which as of now are compiled with:
make distclean; LDFLAGS=-L/package/host/myvendor.com/arm9-linux-toolchain-2.1/prefix/arm-linux/lib CC=/package/host/myvendor.com/arm9-linux-toolchain-2.1/prefix/bin/arm-linux-gcc ~/wd/sources/contrib/axl/configure --prefix=/shared/syst/arm9-linux-abtrack/package/host/aspl.es/axl-0.5.6 --host=armv4tl-unknown-linux-gnu --disable-axl-knife --disable-axl-babel --disable-axl-log --disable-axl-test && make
make distclean; AXL_LIBS="-L/shared/syst/arm9-linux-abtrack/package/host/aspl.es/axl-0.5.6/lib/ -laxl -lm" AXL_CFLAGS=-I/shared/syst/arm9-linux-abtrack/package/host/aspl.es/axl-0.5.6/include/axl CC=/package/host/myvendor.com/arm9-linux-toolchain-2.1/prefix/bin/arm-linux-gcc LDFLAGS="-L/package/host/myvendor.com/arm9-linux-toolchain-2.1/prefix/arm-linux/lib" ~/wd/sources/contrib/vortex/configure --prefix=/shared/syst/arm9-linux-abtrack/package/host/aspl.es/vortex-1.1.0 --disable-http-support --disable-pull-support --disable-tunnel-support --disable-xml-rpc-support-gen --disable-xml-rpc-support --disable-sasl-support --disable-vortex-log --disable-vortex-client --host=armv4tl-unknown-linux-gnu && make
Any autofoo tips for embedding --prefix in compiled libraries?
This is an old question, but I thought I'd add a possible answer anyways.
Just based on the info you've given, could it be that the full path names aren't included for aspl because the aspl libraries you've specified are soft links? If you do a long list on, for instance, /package/host/aspl.es/vortex-1.1.0/lib/libvortex-1.1.so it will show that it's a link to libvortex-1.1.so.0 (with no full pathname).
So, if you still want to embedded the full path, then you need to use the full path to the actual library, not the linked library.