Solved g++ weird behavior: why is g++ using linux compat mode ?

Hello,

I'm trying to build some code which is working fine when built using visual studio on windows and g++ on ubuntu 14.04.

I'm trying to build the code on freebsd 11.1 using gnu g++, but I got some weird behavior I can't understand:
it tries to build using linux compatibility !! Why ?

If I do ldd on a program which is working fine using g++ on freebsd, I have
Code:
    libstdc++.so.6 => /usr/local/lib/compat/libstdc++.so.6 (0x800823000)
   libm.so.5 => /lib/libm.so.5 (0x800b2a000)
   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800d55000)
   libc.so.7 => /lib/libc.so.7 (0x800f63000)

If I try on my program i will complain at runtime:
Code:
/usr/local/lib/compat/libstdc++.so.6: version GLIBCXX_3.4.15 required by /usr/home/rezo/test/deleteme/testapp not found
which is true:
Code:
REZO% strings /usr/local/lib/compat/libstdc++.so.6|grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_FORCE_NEW

If I force using -Wl,-rpath=/usr/local/lib/gcc6 (should not be needed, right ?), I will crash at runtime segfault.
It's not a bug in the program because, if I use gdb and a break on main, it crashs before going to main.
Code:
testapp: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.1, FreeBSD-style, not stripped

Code:
using gdb
(gdb) b main
No symbol table is loaded.  Use the "file" command.
(gdb) r
Starting program: /usr/home/rezo/test/deleteme/testapp

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
You can't do that without a process to debug.
Code:
 ldd ./testapp
./testapp:
   libthr.so.3 => /lib/libthr.so.3 (0x80085f000)
   libboost_system.so.1.65.1 => /usr/local/lib/libboost_system.so.1.65.1 (0x800a87000)
   libboost_thread.so.1.65.1 => /usr/local/lib/libboost_thread.so.1.65.1 (0x800c8b000)
   libstdc++.so.6 => /usr/local/lib/gcc6/libstdc++.so.6 (0x800ea8000)
   libm.so.5 => /lib/libm.so.5 (0x80123d000)
   libgcc_s.so.1 => /usr/local/lib/gcc6/libgcc_s.so.1 (0x801468000)
   libc.so.7 => /lib/libc.so.7 (0x80167e000)
   libc++.so.1 => /usr/lib/libc++.so.1 (0x801a36000)
   libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x801cfd000)

Any idea on what is going on ?
thanks for any help.


PS: sorry ... I posted it in the wrong section of the forum.
it should be on userland application development....
if an admin can move this post, it would be great.
thanks
 
it tries to build using linux compatibility
This has nothing to do with Linux. It's just libstdc++ using the GLIBCXX_ prefix to version its symbols.

FreeBSD uses libc++ by default. Most C++ libraries and programs link with it. When using gcc it uses it's own C++ library (libstdc++) by default. Both are ABI incompatible with each other. In your case Boost is linked to libc++ while your program is being also linked to libstdc++. The result is a crash before your app even starts.

My suggestion is to use clang++ for C++ applications unless you have a very good reason to use g++.
 
Ok, thank you very much.
You are right, this has nothing to do with linux compatibility. My bad. Thank you for this info.

The reason I was using g++ instead of clang++ is because I couldn't compile it with clang++.
The code is very dirty and I will have too much things to fix.

it compiles with clang++ under ubuntu 14.04 , even if with lots of warning, but don't compile on freebsd (because of boost). (I dont remeber which clang version ubuntu use)

There is also something I don't understand.
It seems that when built with clang, I have to add -I/usr/local/include to CFLAGS.
Why is that so ? isn't supposed to be in default search path ?
After that I still have issue like
Code:
In file included from /usr/local/include/boost/function.hpp:64:
In file included from /usr/local/include/boost/preprocessor/iteration/detail/iter/forward1.hpp:52:
In file included from /usr/local/include/boost/function/detail/function_iterate.hpp:14:
In file included from /usr/local/include/boost/function/detail/maybe_include.hpp:18:
/usr/local/include/boost/function/function_template.hpp:159:33: error: called object type 'nullptr_t' is not a function or
      function pointer
          BOOST_FUNCTION_RETURN((*f)(BOOST_FUNCTION_ARGS));
                                ^~~~
It seems I have issue with clang++ and boost library ... that's why I though it would be easier to check what is going on with gcc. Maybe I'm wrong.
 
Back
Top