I tried to follow the instructions on http://www.sigil.org/gwt-on-freebsd/ for building the plugin for the most recent version of Firefox. However linking fails with the error:
g++ -o build/FreeBSD_x86_64-gcc3-ff100/libgwt_dev_ff100.so build/FreeBSD_x86_64-gcc3-ff100/ExternalWrapper.o build/FreeBSD_x86_64-gcc3-ff100/ModuleOOPHM.o build/FreeBSD_x86_64-gcc3-ff100/FFSessionHandler.o build/FreeBSD_x86_64-gcc3-ff100/JavaObject.o build/FreeBSD_x86_64-gcc3-ff100/JSRunner.o build/FreeBSD_x86_64-gcc3-ff100/Preferences.o build/FreeBSD_x86_64-gcc3-ff100/XpcomDebug.o ../common/libcommon64.a -fPIC -shared -m64 -L../../../plugin-sdks/gecko-sdks/gecko-10.0.0/FreeBSD_x86_64-gcc3/lib -Wl,-rpath-link,../../../plugin-sdks/gecko-sdks/gecko-10.0.0/FreeBSD_x86_64-gcc3/lib -lxpcomglue_s -lxpcom -lnspr4 -lmozalloc -lxul
build/FreeBSD_x86_64-gcc3-ff100/ExternalWrapper.o: In function `GenericClassInfo':
/home/bofh/tmp/gwt_build/trunk/plugins/xpcom/../../../plugin-sdks/gecko-sdks/gecko-10.0.0/FreeBSD_x86_64-gcc3/include/nsIClassInfoImpl.h:132: undefined reference to `vtable for GenericClassInfo'
/usr/bin/ld: build/FreeBSD_x86_64-gcc3-ff100/ExternalWrapper.o: relocation R_X86_64_PC32 against `_ZTV16GenericClassInfo' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
gmake: *** [build/FreeBSD_x86_64-gcc3-ff100/libgwt_dev_ff100.so] Error 1
I'm not sure why it complains about missing -fPIC flag because it is present in command line for g++.
Please advice.
the problem was because of wrong SO library used - the one installed by libxul doesn't provide required function, so I copied libxul.so and libxulglue_s.so from firefox installation
and I was able to build the plugin successfully.
=====
after all, I was able to build latest GWT plugin for FreeBSD 9 / Firefox 10 / AMD64, see https://github.com/jdevelop/gwt-dev-firefox-freebsd
Why don't you install it via ports; /usr/ports/www/xpi-gwt-dev-plugin.
If you don't want to do that, at least try applying the patches that the port uses. The patches files/patch-config.mk and files/patch-xpcom-Makefile look relevant to this issue.
Related
I cross-compiled ARMNN for my ARM Cortex-A9 (Debian 9) device on my host system which is x86_64 (Ubuntu 18.04).
I have successfully built ARMNN and all it's dependencies without any errors, but when I try to run the sample mnist on Cortex-A9, it gives the following error:
duu#34d456-45433g:~/ML-examples/armnn-mnist$ make test
arm-linux-gnueabihf-g++ -O3 -std=c++14 -I/home/duu/armnn/armnn/include mnist_caffe.cpp -o mnist_caffe -L/home/duu/build -larmnn -larmnnCaffeParser
/home/admin/build/libarmnn.so: undefined reference to `exp2f#GLIBC_2.27'
/home/admin/build/libarmnn.so: undefined reference to `logf#GLIBC_2.27'
/home/admin/build/libarmnn.so: undefined reference to `log2f#GLIBC_2.27'
/home/admin/build/libarmnn.so: undefined reference to `powf#GLIBC_2.27'
/home/admin/build/libarmnn.so: undefined reference to `expf#GLIBC_2.27'
collect2: error: ld returned 1 exit status
Makefile:12: recipe for target 'mnist_caffe' failed
make: *** [mnist_caffe] Error 1
I figured later that the device should have the same compiler and same GLIBC package, both with same versions as the host on which the library was compiled.
I compiled ARMNN using gcc-6.4.0 and glibc-2.27 on the host and I have gcc-6.3.0 and glibc-2.24 on Cortex-A9 device.
I managed to match the GCC versions and solve the compiler error but I am not able to find matching versions of GLIBC on Ubuntu 18.04 and debian 9.
Is there any way to install a GLIBC version on either of the systems which is common for both of them?
P.S. : Any other method to solve this issue is highly appreciated.
Here is a list of the possible options I can think of right now:
run your application while having LD_LIBRARY_PATH pointing to a directory containing the arm glibc dynamic libraries(v2.27) copied from your x86_64 system - see this post.
Re-compile your application on your target system, if possible, if your target system can use NFS for example,
cross-compile a static version of your library/application, linking it using -static -static-libgcc -static-libstdc++ - see this post.
use arm-linux-musleabihf-cross or one of his friends for cross-compiling a static version of your library/application if this did not work with gcc/g++ and glibc.
run your application in a chrooted environment containing the arm dynamic libraries you linked your application with on the x86_64 system - see this post for more details,
install docker on your Cortex-A9 system, and build a minimal debian/ubuntu docker image that contain a version of debian/ubuntu using glibc 2.27, along with your library and application, and execute the application in a container.
I am trying to compile QtWebApp with Qt5.5.1 onto the latest RPI4-Raspbian Buster and I am encountering inexplicable GLIBCXX unresolved symbols
What Works : QtWebApp cross compiled from windows to armhf using qt5.5.1 binaries natively compiled on Raspbian Buster works fine with the following components
Toolchain : raspberry-gcc8.3.0.exe installed on Windows 10.
Qt Binary Libs : Native compiled on RPI4 Raspbian Buster OS and
copied over to Windows 10.
Command line :
c:/SysGCC/raspberry/bin/arm-linux-gnueabihf-g++.exe -std=c++11 -fPIC -I.
{ALL QT INCLUDE DIRS}
-IC:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/opt/vc/include
-g -rdynamic -funwind-tables -Woverflow
{ALL QTWEB SOURCE FILES}
-LC:/SysGCC/pi4/pi4qt551/lib
-lQt5Core -lQt5Gui -lQt5Widgets
-lQt5Multimedia -lQt5MultimediaWidgets
-lQt5Network -lm -lpthread -o qtweb
This produces an arm executable that worksfine on RPI-4.
What fails
When compiling natively (which is what I want as the development env) on RPI4 the compilation strangely fails with the following error :
/usr/bin/ld: /tmp/ccnnsRCD.o: undefined reference to symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev##GLIBCXX_3.4.21'
What I have tried (didnt work)
1) Following suggestions from Converting std::__cxx11::string to std::string and passing -D_GLIBCXX_USE_CXX11_ABI=0 it fails with the following error :
/usr/bin/ld: /tmp/ccZfI5co.o: undefined reference to symbol '_ZNSaIcED1Ev##GLIBCXX_3.4'
where those symbol demangles to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() and std::allocator<char>::~allocator() respectively.
2) I also ran all the combinations WITH/WITHOUT -std=c++11 and D_GLIBCXX_USE_CXX11_ABI=0 and these are the errors
WITH -std=c++11, WITHOUT -D_GLIBCXX_USE_CXX11_ABI=0
/usr/bin/ld: /tmp/ccnnsRCD.o: undefined reference to symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev##GLIBCXX_3.4.21'
WITH -std=c++11, WITH -D_GLIBCXX_USE_CXX11_ABI=0
/usr/bin/ld: /tmp/ccZfI5co.o: undefined reference to symbol '_ZNSaIcED1Ev##GLIBCXX_3.4'
WITHOUT -std=c++11, WITH -D_GLIBCXX_USE_CXX11_ABI=0
/usr/bin/ld: /tmp/cctFncwz.o: undefined reference to symbol '_ZNSaIcED1Ev##GLIBCXX_3.4'
WITHOUT -std=c++11, WITHOUT -D_GLIBCXX_USE_CXX11_ABI=0
/usr/bin/ld: /tmp/cchkJYdO.o: undefined reference to symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev##GLIBCXX_3.4.21'
3) I also copied the sysroot from the raspberry-gcc8.3.0.exe install on Win10 over to RPi-4 and passed that to gcc as its --sysroot location - which also fails with the ~basic_string() unresolver error. (I dont know how to verify if the --sysroot had any effect though I checked that gcc -v output doesnt have --with_libs in it as suggested in a GCC ignores --sysroot post)
INFO: The command line is exactly the same on the RPI4-Buster other than using gcc and not passing -IC:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/opt/vc/include
Question :
How is it that (assuming no glaring compile option mismatch ;) cross compiling with a gcc 8.3 toolchain from windows to arm-linux works but the same code base when compiled natively on raspbian buster with gcc 8.3 fails with what looks like GLIBCXX version mismatch in the Raspbian Buster OS binaries ?
I am stuck on this for 2 days now. Please suggest any other steps I can try here.
Are you executing the compiler as gcc instead of g++? That would cause this problem. Invoke g++.
Otherwise, Try adding -lstdc++ to your link flags.
Explanation:
The symbols are, obviously, from the C++ standard library. Under some circumstances - at the very least, when you invoke GCC using the gcc binary rather than g++ - GCC compiles C++ code, but doesn't automatically link against the GNU C++ standard library. If for some reason this isn't resolved by invoking g++, you could try adding the -lstdc++ flag, which means "link against the library libstdc++.so or libstdc++.a which you should find in the library search path".
I tried to compile a project from my lab, the only things I changed from the original code using ccmake are:
CMAKE_CXX_COMPILER /usr/bin/clang++
CMAKE_CXX_FLAGS -fPIC -std=c++11
CMAKE_EXE_LINKER_FLAGS -stdlib=libc++
The project also depends from another lib that I compiled using the same options. The compiling works well but the linking fails at some points and give us
/usr/bin/ld: main.cpp.o: undefined reference to symbol '_ZNSsC1EOSs##GLIBCXX_3.4.14'
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: error adding symbols: DSO missing from command line
The code is compiling on another machine but for some reasons, we do not manage to compile on this system. We tried a lot of things without success.
main.cpp.o: undefined reference to symbol '_ZNSsC1EOSs##GLIBCXX_3.4.14'
The -stdlib=libc++ should be used both at link and at compile time. I suspect that adding it to CMAKE_CXX_FLAGS will solve the problem.
I am trying to use the functions from boost::filesystem to change my current working directory (and create it if necessary). I am getting linking errors:
SBDir.cpp:(.text+0x23): undefined reference to `boost::system::generic_category()'
SBDir.cpp:(.text+0x2f): undefined reference to `boost::system::generic_category()'
SBDir.cpp:(.text+0x3b): undefined reference to `boost::system::system_category()'
But I am linking against the boost libraries??!? I use the following:
-lboost_system -lboost_system-mt -lboost_filesystem -lboost_filesystem-mt
And I know it can find them because with -Wl, -t I get:
-lboost_system (/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libboost_system.so)
-lboost_system-mt (/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libboost_system-mt.so)
-lboost_filesystem (/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libboost_filesystem.so)
-lboost_filesystem-mt (/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libboost_filesystem-mt.so)
FWIW: I'm using gcc Ubuntu 4.4.3-4ubuntu54.4.3.
I had this same error message with boost 1.46 (standard with Ubuntu 11.10) and I had to add -lboost_system which I didn't need in 11.04 and boost 1.42. It doesn't answer your question but possibly of interest to others brought here by googling the error message.
So I couldn't figure out what went wrong -- so I tried un-installing the Ubuntu boost package and building it from scratch. I upgraded to 1.45.0 & now everything links. Not sure whether this was a version specific problem or not, but if I learn more later I'll come back and update.
and sorry for my not really good english. I'll try my best :)
I am trying to compile a addin for my Casio graphic calculator in C. This works without problems when using the official SDK. Because it is only available for Windows, I want to use gcc.
So I got sh-rtems-gcc and it's binutils from macports and tried to compile my program according to this instructions. I copy-pasted the described addin.ld and crt0.s and placed my main.c and libfxsys.a (from the same guys as the instructions mentioned above) in the same directory. The sub-dir include contains fxsys' headers. I verified the presence of all the functions of the library in the .a file with nm.
When using this command for compilation:
sh-rtems-gcc-4.2.3 -m3 -mb -nostdlib -I./include -c crt0.s main.c
Everything works fine. But then im trying to link:
sh-rtems-gcc-4.2.3 -m3 -mb -nostdlib -L. -o myaddin.elf -Taddin.ld crt0.o main.o -lfxsys
and get the following error:
main.o: In function `__main':
main.c:(.text+0x248): undefined reference to `_Bdisp_AllClr_VRAM'
...
... (--- cut 16 other errors in the same format ---)
...
main.c:(.text+0x360): undefined reference to `_Sleep'
./libfxsys.a(locate.o): In function `_locate':
locate.c:(.text+0x28): undefined reference to `_locate_OS'
collect2: ld gab 1 als Ende-Status zurück
All the missing symbols are in the libfxsys.a. I have verified this with nm.
I have already played with the positions of the library in the command, as this is often mentioned as a source of failure in other posts found in google, but without success. I also tried adding and removing the -lgcc option that is used in the above mentioned instructions, without success.
My Host-Machine is a Intel Mac, OS X 10.6
Because I have no idea how to solve this problem, and get to compile my program, I have to ask: What am I doing wrong? How can I compile my program without using the SDK?
Thanks in advance,
xythobuz
Edit:
I have also tried linking with:
sh-rtems-ld -EB -L. -o myaddin.elf -Taddin.ld crt0.o --start-group main.o libfxsys.a --end-group
But it produces the same output as above.
I can't say the exact problem, but would investigate like this:
Find the library that contains the missing symbols. Use nm to see symbol names
Once you know which library contains the symbols make sure you're linking to it, and in the correct order. Try using recursive symbol resolution options -( -) with your linker.