I'm building a sample program using kernel extension on AIX 6.1.
Actually, I made a extension file, but I don't know how to import it.
Usually people using IBM C compiler can import this with "-bI:test.esp".
When I used this option for test program. I got the following error.
bash# gcc -o test_prog -bI:import test_prog.c
test_prog.c: In function 'main':
gcc: unrecognized option '-bI:question.esp'
ld: 0711-317 error: unrecognized symbol: .question
collect2: ld returned 8 exit status
That's a linker option so to tell GCC to forward it to the linker use -Wl,-bI:question.esp or -Xlinker -bI:question.esp
Related
When using macOS's built in ld, I get the following error:
ld -arch x86_64 -platform_version macos 11.0 12.2.1 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -lSystem -lc++ -o /Users/blashyrk/Documents/source/nim/asserttrigger /Users/blashyrk/.cache/nim/asserttrigger_d/asserttrigger.o
Undefined symbols for architecture x86_64:
"_nlvmEHPersonality", referenced from:
Dwarf Exception Unwind Info (__eh_frame) in asserttrigger.o
ld: symbol(s) not found for architecture x86_64
However, that symbol is a function that's defined inside that very same object file.
Using objdump on the object file, I can confirm that the function is indeed there:
objdump -t ~/.cache/nim/asserttrigger_d/asserttrigger.o | grep nlvmEH
00000000000063b0 l F __TEXT,__text _nlvmEHPersonality
And just to make sure I wasn't crazy, I decided to see for myself with Ghidra (please see attached image).
So my question is, what makes macOS's ld not find this symbol? When using LLVM's lld it works, so the symbol is defined properly.
Am I, perhaps, missing a flag? Is ld expecting the EH personality function to be a part of some external object/library?
Here's also a link to the object file, if someone wants to try it out on their end: https://www46.zippyshare.com/v/0UFxM7zD/file.html
The program (if you manage to link it successfully) should run and exit with no output.
I've gotten it to work by changing the linkage type of nlvmEHPersonality from internal to external.
For some reason, ld64 cant't find it with internal linkage even though lld can.
Environment
$ lsb_release -a
Description: Ubuntu 20.04.2 LTS
$gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Problem
link error happens depending on the position of input file.
NG
$gcc -lsndfile -o snd-003 snd-003.c
/usr/bin/ld: /tmp/ccMmdgxh.o: in function `main':
snd-003.c:(.text+0x5c): undefined reference to `sf_open'
/usr/bin/ld: snd-003.c:(.text+0x88): undefined reference to `sf_readf_short'
/usr/bin/ld: snd-003.c:(.text+0xc4): undefined reference to `sf_close'
collect2: error: ld returned 1 exit status
OK
If you change the argument position of input file, then link error does not happen.
$gcc snd-003.c -lsndfile -o snd-003
Other info
snd-003.c is uploaded below (just FYI).
https://file.io/PA4K22CzXwsi
this problem happens on other gcc version
gcc 8.4.0
gcc 7.5.0
this error happens on other libraries too (e.x. libssl).
there is no this problem on other machines.
deiban 10.9 (gcc 8.3.0)
debian 8.3 (gcc 4.9.2)
similar problem reported long time ago, but it's not solved.
strange g++ linking behavior depending on arguments order
Question
Does anyone have some clue on what's wrong with this ? gcc ? environment ?
I want to know the root cause of this behavior.
Any comments are really appreciated.
I guess this is the expected behavior (https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_3.html):
The linker will search an archive only once, at the location where it is specified on the command line. If the archive defines a symbol which was undefined in some object which appeared before the archive on the command line, the linker will include the appropriate file(s) from the archive. However, an undefined symbol in an object appearing later on the command line will not cause the linker to search the archive again. See the -( option for a way to force the linker to search archives multiple times.
I am currently trying to make and install a specialist suite of software (https://github.com/scottransom/presto), and am encountering this error:
gfortran -g -fPIC -o /path-to/presto/bin/psrorbit powerplot.o xyline.o psrorbit.o -L/usr/local/Cellar/cfitsio/3.450/lib -lcfitsio -lcurl -L/path-to/presto/lib -lpresto -L/usr/local/lib -lfftw3f -L/usr/local/lib/pgplot -lcpgplot -lpgplot -L/opt/X11/lib -lX11 -L/opt/X11/lib -lpng16 -lm
ld: mach-o string pool extends beyond end of file in /usr/local/lib/libcpgplot.dylib file '/usr/local/lib/libcpgplot.dylib' for architecture x86_64
collect2: error: ld returned 1 exit status
make: *** [psrorbit] Error 1
I don't think it's a problem related to PRESTO per se, as several searches (see this, this, and this) point to something fundamental, perhaps with Xcode. I currently have version 11.3, and I also installed the command line tools. So again, what does the error itself mean? Any help would be useful!
According to my reading of the source code for Apple's version of ld, this error means that the symbol table in an object prematurely ends when the file does.
There appear to be quite a few sanity checks performed on object files when linking. Likely, your copy of /usr/local/lib/libcpgplot.dylib is corrupt.
I am compiling a C++ program using make, this is the error i'm getting.
/usr/bin/ld: fglut/libfglut.a(freeglut_state.o): undefined reference to symbol 'XGetWindowAttributes'
//usr/lib/i386-linux-gnu/libX11.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:55: recipe for target 'morphlines' failed
make: *** [morphlines] Error 1
I'm beginner
/usr/bin/ld: fglut/libfglut.a(freeglut_state.o):
This tells me you link libfglut statically (*.a is just an archive of object files). When you do this, you must link all dependencies as well, because with the object files from the static library actually compiled into your program, your program will depend on them.
Either link libfglut dynamically (this is the default with the GNU toolchain), so your program will depend on libfglut.so which will itself depend on libX11.so -- or add -lX11 after -lfglut on the command line of your final linking step. You might need -Wl,-Bdynamic before -lX11 to switch the linker back to dynamic linking.
If this doesn't directly solve your problem, I suggest you edit your question to include the relevant parts of the Makefile you're using.
I built gcc 4.9.0 from source, and was also planning on building clang 3.4.2, however something seems to have gone awry with regards to libstdc++, as the clang build baled pretty quickly with the linker complaining about various undefined references from std.
Indeed, I then tried compiling and linking the trivial program:
#include <iostream>
int main() {
std::cout << 42;
}
and again hit linker errors:
/tmp/ccrptgVW.o:temp.cpp:function main: error: undefined reference to 'std::cout'
/tmp/ccrptgVW.o:temp.cpp:function main: error: undefined reference to 'std::ostream::operator<<(int)'
/tmp/ccrptgVW.o:temp.cpp:function __static_initialization_and_destruction_0(int, int): error: undefined reference to 'std::ios_base::Init::Init()'
/tmp/ccrptgVW.o:temp.cpp:function __static_initialization_and_destruction_0(int, int): error: undefined reference to 'std::ios_base::Init::~Init()'
collect2: error: ld returned 1 exit status
(full gcc -v output), both with my freshly-minted gcc 4.9.0 and my Ubuntu's stock gcc 4.6.3.
libstdc++.so exists, in /usr/local/lib64:
ls /usr/local/lib64/libstd*
/usr/local/lib64/libstdc++.a
/usr/local/lib64/libstdc++.so
/usr/local/lib64/libstdc++.so.6.0.20
/usr/local/lib64/libstdc++.la
/usr/local/lib64/libstdc++.so.6
/usr/local/lib64/libstdc++.so.6.0.20-gdb.py
and this directory appears in LIBRARY_PATH and as an -L argument to collect2 in the verbose gcc output.
How do I restore sanity to my system and have the linker find the shared library?
As turns out from your comment, you compiled with gcc rather than g++.
Do not take it as an error, as the compilation went fine! What's showing up is a linker error. Indeed, gcc will tell ld to link against the C standard library rather than the C++ standard one.
To solve, either go for g++ directly or pass -lstdc++.