I am trying to build a 64-bit binary from C++ code using 32-bit g++ compiler.
I am getting the following errors while building:
=> /usr/local/bin/g++ -shared -maix64 -fPIC -Wl,-bM:SRE -Wl,-bnoentry -Wl,-bE:gcc_shr_lib.so.exp -o gcc_shr_lib.so gcc_shr_lib.o -L/usr/local/lib
ld: 0711-319 WARNING: Exported symbol not defined: gcc_whereAmI
ld: 0711-317 ERROR: Undefined symbol: typeinfo for std::bad_alloc
ld: 0711-317 ERROR: Undefined symbol: __gxx_personality_v0
ld: 0711-317 ERROR: Undefined symbol: vtable for std::exception
ld: 0711-317 ERROR: Undefined symbol: vtable for std::bad_alloc
ld: 0711-317 ERROR: Undefined symbol: .std::ios_base::Init::Init()
ld: 0711-317 ERROR: Undefined symbol: .std::ios_base::Init::~Init()
ld: 0711-317 ERROR: Undefined symbol: .operator new(unsigned long)
ld: 0711-317 ERROR: Undefined symbol: .operator delete(void*)
ld: 0711-317 ERROR: Undefined symbol: ._Unwind_Resume
ld: 0711-317 ERROR: Undefined symbol: .__cxa_get_exception_ptr
ld: 0711-317 ERROR: Undefined symbol: .__cxa_begin_catch
ld: 0711-317 ERROR: Undefined symbol: std::cout
ld: 0711-317 ERROR: Undefined symbol: .std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)
ld: 0711-317 ERROR: Undefined symbol: std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)
ld: 0711-317 ERROR: Undefined symbol: .std::basic_ostream<char, std::char_traits<char> >::operator<<(std::basic_ostream<char, std::char_traits<char> >& (*)(std::basic_ostream<char, std::char_traits<char> >&))
ld: 0711-317 ERROR: Undefined symbol: .std::bad_alloc::~bad_alloc()
ld: 0711-317 ERROR: Undefined symbol: .__cxa_end_catch
ld: 0711-317 ERROR: Undefined symbol: .__register_frame_info_table
ld: 0711-317 ERROR: Undefined symbol: .__deregister_frame_info
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
It seems I need 64-bit libstdc++ available on my build system. Could someone please throw some light on to solve this?
Is it OK to build 64-bit binaries using 32-bit g++ compiler on AIX 5.2?
Where should I get 64-bit libstdc++? Will this 64 bit libstdc++ work with 32-bit g++ compiler?
Thanks a lot for your quick response and for pointing out the problem.
Following are the versions of GCC/G++ I am using:
=> gcc -v
Using built-in specs.
Target: powerpc-ibm-aix5.2.0.0
Configured with: ../gcc-4.1.1/configure --disable-aix64 --disable-nls
Thread model: aix
gcc version 4.1.1
[tsivaram#maroon /]
=> g++ -v
Using built-in specs.
Target: powerpc-ibm-aix5.2.0.0
Configured with: ../gcc-4.1.1/configure --disable-aix64 --disable-nls
Thread model: aix
gcc version 4.1.1
Since gcc and g++ are configured/built with --disable-aix64, there are no 64-bit STD libraries available (Ex: libstdc++).
AIX version i am using:
=> uname -a
AIX maroon 2 5 000663FC4C00
[tsivaram#maroon /]
=> oslevel
5.2.0.0
[tsivaram#maroon /]
=> oslevel -r
5200-05
How can I build 64-bit libstdc++, which should work with gcc/g++ 4.1.1?
Do I need to rebuild GCC and G++ without the --disable-aix64 flag? If yes, could you please point to me a link explaining how to build?
Can not we just build libstdc++ library (required)?
You seem to be building a shared library rather than an executable.
As long as the relevant 64-bit libraries are available on the machine, it should not matter whether your G++ is itself a 32-bit or a 64-bit binary - it should be able to generate both 32-bit and 64-bit object files (and shared libraries, and executables, etc).
Be aware that GCC (or G++) uses a different name-mangling scheme from other compilers quite deliberately - because it does various things (such as exception handling, class layouts and the like) differently from other compilers. You cannot reliably link code compiled with the native XLC compilers with code compiled with G++. However, you do not seem to be doing that here.
You should look under /usr/local/lib to see what you can find in the way of 64-bit C++ libraries; you may need to mention the right directory and shared library name on the command line. Alternatively, add the '-v' flag to the command and see what is actually being executed.
You seem to just have missing symbols; you don't have mismatched 32-bit vs 64-bit object files or libraries or whatever. So, you're close - just not quite there yet.
(Is AIX 5.2 still supported? Shouldn't you be planning to move to 5.3 or 6.1?)
Related
I installed opencv by brew, I tried to reinstall for several times and it didn't help. I have googled for a lot of time but didn't find a valid way to solve this.
I copied a valid opencv from my friend's mac, but the imwrite function is still not found on my mac
Please help.
bash: g++ $(pkg-config --cflags --libs opencv) BoxFilter.cc -o BoxFilter
In file included from /usr/local/Cellar/opencv/3.3.0_3/include/opencv2/core.hpp:54:0,
from /usr/local/Cellar/opencv/3.3.0_3/include/opencv2/opencv.hpp:52,
from BoxFilter.cc:2:
/usr/local/Cellar/opencv/3.3.0_3/include/opencv2/core/base.hpp:354:35: warning: unknown option after '#pragma GCC diagnostic' kind [-Wpragmas]
# pragma GCC diagnostic ignored "-Winvalid-noreturn"
^
Undefined symbols for architecture x86_64:
"cv::imwrite(cv::String const&, cv::_InputArray const&, std::vector<int, std::allocator<int> > const&)",referenced from:
_main in ccO7bsE6.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
I'm working on a Mac. I installed libprotobuf with brew install protobuf --c++11.
17:51 $ brew info protobuf
protobuf: stable 2.6.1 (bottled), devel 3.0.0-beta-4, HEAD
Protocol buffers (Google's data interchange format)
https://github.com/google/protobuf/
/usr/local/Cellar/protobuf/2.6.1 (149 files, 7.0M) *
Built from source on 2016-08-02 at 17:42:15 with: --c++11
libprotobuf.dylib lives in /usr/local/Cellar/protobuf/2.6.1/lib.
I wrote the following dummy app hoping to invoke this constructor:
// test.cc
#include <string>
#include <google/protobuf/io/coded_stream.h>
#include <google/protobuf/io/zero_copy_stream_impl_lite.h>
int main() {
std::string s{"hello"};
google::protobuf::io::StringOutputStream sos(&s);
}
When I compile the app, I get an undefined reference error:
17:55 $ g++ -L/usr/local/Cellar/protobuf/2.6.1/lib -std=c++14 test.cc -lprotobuf
Undefined symbols for architecture x86_64:
"google::protobuf::io::StringOutputStream::StringOutputStream(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)", referenced from:
_main in ccyQlDM5.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
When I check the .dylib for StringOutputStream, it's a little wonky.
17:56 $ nm /usr/local/Cellar/protobuf/2.6.1/lib/libprotobuf.dylib | c++filt | grep "StringOutputStream(std::"
000000000000e3ac T google::protobuf::io::StringOutputStream::StringOutputStream(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*)
000000000000e398 T google::protobuf::io::StringOutputStream::StringOutputStream(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*)
Why is basic_string namespace-prefixed by ::__1 in my list of symbols for that .dylib? How can I fix this?
If this isn't a problem (perhaps an artifact of unmangling), why am I still receiving an undefined reference to a constructor call I know to be defined?
I'm using gcc 5.3.0 to compile test.cc.
As referenced in the comments, Homebrew was building with clang instead of g++.
I removed the protobuf installed by brew, checked out and built the source, copied the new .dylib to /usr/local/lib and it worked fine.
I have just started working with Luabind, and have attempted to run the Hello World test specified at http://www.rasterbar.com/products/luabind/docs.html#calling-lua-functions. However, this provides an undefined symbol error when attempted to compile.
Undefined symbols for architecture x86_64:
"luabind::scope::scope(std::__1::auto_ptr<luabind::detail::registration>)", referenced from:
luabind::scope luabind::def<void (*)(), luabind::detail::null_type>(char const*, void (*)(), luabind::detail::null_type const&) in TestClass.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Other functions such as luabind::open and luabind::call_function work correctly.
I installed both luabind and lua 5.1 through homebrew on osx.
It looks to me like you are compiling your program against libc++ and trying to link to a luabind library that was compiled against the stdlibc++ library.
The clue is std::__1::auto_ptr. This __1 inline namespace is used by libc++ to differentiate it's ABI from stdlibc++
Thus if
luabind::scope::scope(std::__1::auto_ptr<luabind::detail::registration>)
Cannot be found it is likely because libluabind doesn't have it. Dumping it's exported symbols you might find it has
luabind::scope::scope(std::auto_ptr<luabind::detail::registration>)
Instead.
If I am right, simply recompile libluabind targeting libc++ and you should find it works with your test program.
I'm fairly new to the AIX platform. Currently porting an application from linux to AIX.
I know timeradd and timersub aren't supported on AIX which is why I get the following error:
ld: 0711-317 ERROR: Undefined symbol: .timeradd
ld 0711-317 ERROR: Undefined symbol: .timersub
ld 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
Is there a workaround? Or a patch for the definitions?
GCC 4.5 added support for decimal floating points in the runtime library (http://gcc.gnu.org/gcc-4.5/changes.html). I'm able to compile code including , using namespace std::decimal, then using decimal64 and so on in the code.
Unfortunately, I'm missing some library for linking the code. I've not been able to find out which libraries should be required. DFP support is enabled in gcc (--enable-decimal-float=dpd)
Additionally, should there be some fast way of providing decimal literals in the code? By fast, I mean user defined literals that are handled by templates and translated at compile time. I do not want to provide doubles that are converted at runtime (despite performance and the fact that I really can't stand moving evaluations from compile time to runtime there are still rounding issues...). I've already found the suffix "df" but that does not seem to be recognized by the compiler.
I'm using gcc version 4.7.1 on target powerpc-ibm-aix7.1.0.0.
Linker error messages:
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatsisd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatsidd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatsitd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_mulsd3
ld: 0711-317 ERROR: Undefined symbol: .__dpd_muldd3
ld: 0711-317 ERROR: Undefined symbol: .__dpd_multd3
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatdisd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatunsdisd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatdidd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatunsdidd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatditd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatunsditd
TIA.
I've recently compiled gcc4.7.1 from source and had trouble with missing symbol __floatunsidf. This turned out to be a symbol required by libstdc++.so and defined in libgcc_s.so. Given that both Libraries are provided by gcc they should be compatible. In my case i still had a linker include to an old version of libgcc_s that i'd lifted from my target platform. Its probably worth doing
# to find out where libstdc++.so is:
gcc -print-file-name=libstdc++.so
# see if it references the symbol you're missing
readelf -a "path to libstdc++.so" | grep "symbol name"
and then doing the same for libgcc_s to see if they both define the symbol you are missing. Nb one will mark the symbol as undefined - thats how the linker knows its required.