I used the MinGW .a to Windows .lib transformation process as detailed in a
thread on the gmp-discuss list, as below (acting against a library created with --disable-shared --enable-static.)
cp libgmp.a gmp.a
ranlib gmp.a
mv gmp.a gmp.lib
I now have a .lib file against which VC++6 seems to have no difficulty linking. What concerns me now is warning messages I'm getting from the link phase:
LINK : warning LNK4049: locally defined symbol "___mb_cur_max" imported
LINK : warning LNK4049: locally defined symbol "__pctype" imported
LINK : warning LNK4049: locally defined symbol "__iob" imported
At this point in the proceedings these make no difference to the running of
my DLL (which wraps certain GMP functionality). But is that good enough?
Will having these three symbols from libgmp.a linked in to my Windows DLL
end up biting me later on?
Someone else had a similar problem and the fix was relatively simple.
Related
I am porting a large C++ library (libcoro.so) and example application (coro-example.cpp) from Windows to RedHat Linux 7.4. I have very little development experience on Linux, so this is probably a 'newbie' question. I have libcoro and the example app compiling, linking, and running on my RHEL 7.4 VM. However, the gcc linker fails to link the app on the customer's RHEL 7.4 machine when he tries to link coro-example.o to libcoro.so. The error message is:
/usr/bin/ld: warning: libusb-0.1.so.4, needed by ./bin/libcoro.so not
found (try using -rpath or -rpath-link) libcoro.so: undefined
reference to 'usb_open' libcoro.so: undefined reference to
'usb_release_interface' ...etc...
Running 'ldd coro.so' on my machine displays:
libusb-0.1.so.4 => /lib64/libusb-0.1.so.4 (0x00007f71115db000)
...etc...
And on the customer's machine:
libusb-0.1.so.4 => not found [many other libs] => not found ...etc...
Indeed, these libraries are in my /lib64 folder, but are not in the customer's. I'm not sure how they got installed on my machine. I have access to the missing libraries and can deliver them with my libcoro.so library. I really want my app to be self-contained and run on any RHEL 7.x machine. My question is:
What is the best way to identify which libraries are not part of the RHEL 7.x installation and have the linker fail on my machine if I'm not delivering a local copy? I tried linking with -nodefaultlibs, but the link fails on functions like printf() and I haven't found a way to locate these standard libraries. They don't appear to be in /lib64.
Is there a way to exclude /lib64 from the default library search?
There is a linker switch -Wl,--no-undefined which seems to do what I want. It fails to link and generates an error is the library is isn't explicitly named. Also, the command ldd libcoro.so lists all dependencies and where they are being resolved. I also found this this article very helpful.
Using Android NDK R10E, I am trying to build a shared library for all supported ABI's and I am getting the following error for some but not all ABI's:
[armeabi] SharedLibrary : libMyLib.so /home/user/android-ndk-r10e/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld:
fatal error: /home/user/source/MyLib/obj/local/armeabi/libMyLib.so: Input/output error
The project successfully builds for arm64-v8a, mips and mips64 but fails with the above error for armeabi, armeabi-v7a, x86 and x86_64.
I have a static library project and another shared library project and they both build successfully for all 7 ABI's.
If I compare the contents of obj/local/ for an ABI that builds and one that does not, they both contain all the same files except for libMyLib.so.
The difference between those two sets of ABIs is that the failing ones link using ld.gold and the working ones use ld.bfd.
Two things to try:
Use the 4.9 toolchain. It hopefully has the bug fix.
If that doesn't work, you can add -fuse-ld=bfd to your ldflags to use bfd even on the architectures that default to gold.
Same issue happened to me in r15c.
The fix was to copy
android-ndk-r15c/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld.bfd over ld.
I had to copy it because I could not easily find a way to specify this flag to CMake to use it while detecting the compiler features.
I am following this site to compile OpenCV for ARM.
It could not find my compiler so i hardcoded it into cmake file
find_program(CMAKE_C_COMPILER NAMES arm-linux-gnueabi-gcc-4.7)
find_program(CMAKE_CXX_COMPILER NAMES arm-linux-gnueabi-g++-4.7)
set(ARM_LINUX_SYSROOT /usr/arm-linux-gnueabi CACHE PATH "ARM cross compilation system root")
It compiles to aproximately 50% and then throws the following error:
Linking CXX shared library ../../lib/libopencv_viz.so
/usr/lib/libvtkCharts.so.5.8.0: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
I am not every experienced in cross compilation (or straight compilation for the matter). How do i fix this?
I think it is a mismatch between libopencv_viz and libvtkCharts. Some of your 3rdparty libs are built for another platform. These libraries themselves must be recompiled from source to match the details (ABI, dynamic system library dependencies, etc) of the system on which they are intended to be used.
Compiling OpenCV 2.4.10 worked for me. I did not have any preferred version. If you want to compile v3.0 see #Kornel's answer, that suggests to leave viz library out of compilation.
Use this command to checkout v2.4.10
git checkout 2.4.10
I have been using volk in some of our internal components if the volk library is detected on the system. I know that GNUHawk packages a version of volk in the deps folder within SDRROOT. We just created a new Linux image with CentOS 6.6 and Redhawk 1.10.0-10 installed from the RPMs available online. Previously we had been building gnuhawk from source. When running our custom components we get symbol lookup errors due to the symbol table having been stripped from libvolk that is packaged with RPM version of gnuhawk.
What is a suggested way around this issue? Should we create another softpackage dependency with our own version of libvolk in it instead of using the gnuhawk libvolk?
You shouldn't have any issues using the volk shared objects packaged with gnuhawk but I'd have to get more info to know for sure what's going on. My guess is that you may be compiling against a system install of libvolk and then running against the gnuhawk version which could cause a symbol look-up issue.
Make sure you are compiling and linking against the volk files within the SDRROOT. You should be able to use the pc file ($SDRROOT/sdr/dom/deps/gnuhawk/lib/pkgconfig/volk.pc) to setup your CXX & LD Flags automatically with autotools
You can see the symbols within the libvolk object using readelf. Use readelf -s on the libvolk.so.0.0 shared object and it should print out the symbol table. You can then confirm the symbol in question is missing and start hunting for how you were linked against that symbol in the first place.
You can of course create your own shared object library with your volk headers & shared objects. This gives you the flexibility to update volk and breaks your dependence on gnuhawk.
I am building GCC-4.4.2 ( open embedded recipe using bitbake version-1.8 ) for an x86 based system.
The configure options are as under:
"--enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap"
It builds successfully after some minor changes and libstdc++.so.6.0.13 library is getting created.
My aim is to run Citrix receiver on an x86 based target. For this, I run storebrowse as follows:
./usr/lib/ICAClient/storebrowse
But I get the following errors.
./storebrowse: /usr/lib/libxml2.so.2: no version information available (required by ./storebrowse)
./storebrowse: relocation error: ./storebrowse: symbol _ZTISt15basic_streambufIwSt11char_traitsIwEE, version GLIBCXX_3.4 not defined in file libstdc++.so.6 with link time reference.
libxml2 error can be resolved by deleting and creating a new symbolic link to libxml. I am unable to resolve the symbol error (_ZTISt15basic_streambufIwSt11char_traitsIwEE). I am compiling using default gcc_4.4.2.bb recipe.
Do I need to make any changes in configure options..?
It looks like your executable is loading the system's (older) libstdc++. To fix this, either configure GCC with --enable-rpath or explicitly add RPATH to your call to g++ with -Wl,-rpath=/path/to/your/gcc/lib, or run your executable like this:
LD_LIBRARY_PATH=/path/to/your/gcc/lib ./usr/lib/ICAClient/storebrowse
I wrote those three possible solutions in order of my personal preference. :)
This page may be of some interest: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html