-bash3-3.00$ gcc -v Using built-in specs. Target: mips-sgi-irix6.5 Configured with: ../gcc-4.0.0/configure --cache-file=../configure.cache --prefix=/usr/gnu --bindir=/usr/gnu/bin --sbindir=/usr/gnu/sbin --libdir=/usr/gnu/lib32 --disable-nls --disable-multilib --disable-intl --with-gnu-as --with-as=/usr/gnu/bin/mips-sgi-irix6.5-as --with-gnu-ld --with-ld=/usr/gnu/bin/mips-sgi-irix6.5-ld --enable-languages=c,c++ Thread model: single gcc version 4.0.0 Problem: When linking the executable with -lC or -lpthreads the linker (GNU ld version 2.16 complains: /usr/lib/../lib32/libC.so: undefined reference to `_mpi_sgi_init' /usr/lib32/libpthread.so: undefined reference to `_mpi_sgi_init' This makes compiling a lot of programms impossible. , (Qt and Motif for example, but also gdb). Comandline: g++ -fno-exceptions -o sliders .obj/debug-shared/main.o .obj/debug-shared/slidersgroup.o .obj/debug-shared/window.o .obj/debug-shared/moc_slidersgroup.o .obj/debug-shared/moc_window.o -L/usr/compile/Trolltech/Qt/qt-x11-commercial-desktop-4.0.0/lib -L/usr/compile/Trolltech/Qt/qt-x11-commercial-desktop-4.0.0/lib -lQtGui_debug -lSM -lICE -lXext -lX11 -lm -lQtCore_debug -lC -lpthread
*** Bug 1151 has been marked as a duplicate of this bug. ***
I built gcc-4.0.1 with binutils-2.16.1 as/ld on mips-sgi-irix6.5 and tried to link Qt-4.0.0. The result was this error: /usr/lib32/libpthread.so: undefined reference to `_mpi_sgi_init' $ nm /usr/lib32/libpthread.so | grep _mpi_sgi_init [217] | 0| 0|FUNC |GLOB |OPTIONAL |UNDEF |_mpi_sgi_init I take it binutils-2.16.1 ld on mips-sgi-irix6.5 doesn't support OPTIONAL symbols yet? Anyone working on this? Anyone know the status of GNU ld on mips-sgi-irix6.5? This Errorreport showed up alread on: http://sourceware.org/ml/binutils/2005-06/msg00621.html PLEASE ! Fix this, elsewhise the gcc 4.0 is not useable on IRIX and this leaves all the older SGI machines behind! PLEASE !
I ran into this one as well on IRIX-6.5.28m with gcc-4.0.1 and binutils-2.16.1. Why is this bug in status WAITING? Is more input required? I can provide testing and debugging if required.
Subject: Re: undefined reference to `_mpi_sgi_init' Hi Michael, > I ran into this one as well on IRIX-6.5.28m with gcc-4.0.1 and binutils-2.16.1. > Why is this bug in status WAITING? Is more input required? I can provide testing > and debugging if required. Can you provide a specification for these OPTIONAL symbols ? Cheers Nick
I don't have any information beyond the error message and what I learned from the message to the mailing list quoted above. The behaviour of OPTIONAL symbols seems to be that they're silently ignored if not present in any of the linked objects, allowing for using libraries if linked against but working anyway if missing. In the case of libpthread this seems to silently recognize linkage against mpi and doing a call into mpi to make it aware of pthreads being used (or the like). Some googling reveals the following resources on optional symbols: 64-bit ELF Object File Specification: http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-4658-001.pdf #pragma optional in MIPSpro cc: http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&srch=&fname=/SGI_Developer/Pragmas/sgi_html/ch07.html optionalsym: http://biology.ncsa.uiuc.edu/cgi-bin/infosrch.cgi?cmd=getdoc&db=man&fname=/usr/share/catman/u_man/cat1/optionalsym.z mips st_other and STO_OPTIONAL: http://koolkat2.cs.rice.edu/cgi-bin/cvsweb.cgi/Open64/osprey1.0/linux/include/Attic/elf.h?rev=1.2 Especially the 64-bit Object File Specification seems to contain quite some background on this. BTW: I encountered the problem with a gcc-4.0.1 configured with --with-abi=64 when compiling and linking 64 bit objects/executables.
Subject: Re: undefined reference to `_mpi_sgi_init' Hi Michael, > I don't have any information beyond the error message and what I learned from > the message to the mailing list quoted above. The behaviour of OPTIONAL symbols > seems to be that they're silently ignored if not present in any of the linked > objects, allowing for using libraries if linked against but working anyway if > missing. In the case of libpthread this seems to silently recognize linkage > against mpi and doing a call into mpi to make it aware of pthreads being used > (or the like). Ok - this appears to be an Irix specific extension to the ELF spec. An extension which is not currently supported by the binutils. Do you have a *small* self-contained example that can reproduce the problem ? Preferably one that can be run using a cross-compiler as I do not have access to an Irix host. Failing that, can you supply a binary that contains one of these OPTIONAL symbols so that I can investigate further ? In the meantime if you would like to try out the patch I am uploading to the PR, you may find, just possibly, that it helps. Cheers Nick
Created attachment 752 [details] attempt to ignore OPTIONAL symbols
Created attachment 753 [details] testcase for optional symbols Okay, I gave it a try to build a testcase. It's included in the attachment. It's using the irix as to produce some object files using optional symbols. Then it links them using irix ld as well as binutils ld to demonstrate where binutils ld fails. This should be reproducable with a cross-ld for elf64bmip. The files are: os.s: defines a dword named os with value 73 which is read from ot.s ot.s: has a function ot which reads the value of os if it is linked in, otherwise returns -1. The linkage detection is done using the special libc-symbol __missing_function_. If the linker can't find the definition of an optional symbol it maps it to __missing_function_ which is defined in libc.so. This one is optional and weak itself. The program can detect at runtime if a specific symbol is compiled in by comparing its address to that of __missing_function_. If they're equal the symbol has been mapped and not compiled in. If they're different, the symbol is actually present. start.s: defines __start, _environ and __missing_function_ to allow link tests without actually having the irix crt1.o, crtn.o and libc.so around. The resulting binaries will segfault but binutils ld will fail linking before that. otw.s: is dynamically generated from ot.s by adding a .weakext os definition. By accident I discovered that binutils ld will link the objects if os is defined weak external. But the resulting executable will segfault or give bogus results, so it isn't actually worth much. The above files are compiled into objects and linked into binaries. Executables ending in -bu are linked using binutils ld, the others by using irix ld. The meaning is as follows: ot-opt: linking ot.o and os.o into a binary so that the optional symbol can be resolved, works with both ld's ot-noopt: linking ot.o without os.o so that the optional symbol can't be resolved and has to be mapped to __missing_function_ otw-*: same as above but using the weak-external-defined os, works with both ld's but gives bogues executable with binutils ld. Output on irix looks like this when doing make all to link the programs using irix ld: [michael@tharbad ot]$ make all as -64 -o start.o start.s as -64 -o ot.o ot.s as -64 -o os.o os.s ld -64 -o ot-opt /usr/lib64/mips4/crt1.o ot.o os.o /usr/lib64/mips4/crtn.o -lc ld -64 -o ot-noopt /usr/lib64/mips4/crt1.o ot.o /usr/lib64/mips4/crtn.o -lc sed -e "s,/\* \(.weak.*\) \*/,\1," ot.s >otw.s as -64 -o otw.o otw.s ld -64 -o otw-opt /usr/lib64/mips4/crt1.o otw.o os.o /usr/lib64/mips4/crtn.o -lc ld -64 -o otw-noopt /usr/lib64/mips4/crt1.o otw.o /usr/lib64/mips4/crtn.o -lc ./ot-opt *** Error code 73 (bu21) (ignored) ./ot-noopt *** Error code 255 (bu21) (ignored) ./otw-opt *** Error code 73 (bu21) (ignored) ./otw-noopt *** Error code 255 (bu21) (ignored) The error codes carry the information: ot-opt and otw-opt have os compiled in and return its value 73. ot-noopt and otw-noopt don't have os compiled in and give -1. With binutils ld it looks as follows: [michael@tharbad ot]$ make bu as -64 -o start.o start.s as -64 -o ot.o ot.s as -64 -o os.o os.s /usr/local/bin/ld -melf64bmip -o ot-opt-bu /usr/lib64/mips4/crt1.o ot.o os.o /usr/lib64/mips4/crtn.o -lc /usr/local/bin/ld -melf64bmip -o ot-noopt-bu /usr/lib64/mips4/crt1.o ot.o /usr/lib64/mips4/crtn.o -lc ot.o: In function `main': /home/michael/ot/ot.s:27: undefined reference to `os' /home/michael/ot/ot.s:38: undefined reference to `os' *** Error code 1 (bu21) (ignored) sed -e "s,/\* \(.weak.*\) \*/,\1," ot.s >otw.s as -64 -o otw.o otw.s /usr/local/bin/ld -melf64bmip -o otw-opt-bu /usr/lib64/mips4/crt1.o otw.o os.o /usr/lib64/mips4/crtn.o -lc /usr/local/bin/ld -melf64bmip -o otw-noopt-bu /usr/lib64/mips4/crt1.o otw.o /usr/lib64/mips4/crtn.o -lc [ -x ot-opt-bu ] && ./ot-opt-bu *** Error code 73 (bu21) (ignored) [ -x ot-noopt-bu ] && ./ot-noopt-bu *** Error code 1 (bu21) (ignored) [ -x otw-opt-bu ] && ./otw-opt-bu *** Error code 73 (bu21) (ignored) [ -x otw-noopt-bu ] && ./otw-noopt-bu *** Termination code 139 (bu21) (ignored) ot-opt-bu and otw-opt-bu work, but ot-noopt-bu doesn't link and otw-noopt-bu segfaults. I can reproduce the link problem with a elf64bmip binutils ld on may Mac OS X 10.3 iBook: michael@brithombar:~/nobak/src/ot # PATH=/Users/michael/bin/cross-mips-sgi-irix6.5/mips-sgi-irix6.5/bin/:$PATH make ot-noopt-bu ld -melf64bmip -o ot-noopt-bu start.o ot.o ot.o: In function `main': /home/michael/ot/ot.s:27: undefined reference to `os' /home/michael/ot/ot.s:38: undefined reference to `os' make: [ot-noopt-bu] Error 1 (ignored) All necessary object files are included. There may still be some braindamage in the whole testcase due to misunderstandings on my part. I certainly don't hope so but I'm not that much of an mips assembler or irix linker crack. :) BTW: I produced the assembler code by writing short snippets of C code, compiling them into assembler using gcc-4.0.2 and adding the optional symbol stuff then. So the asm should be reasonable okay. Hope it helps.
Sorry, the attachment lost its name: it's a gzipped tarball (ot.tar.gz).
Subject: Re: undefined reference to `_mpi_sgi_init' Hi Michael, > Okay, I gave it a try to build a testcase. It's included in the attachment. Thanks. I was not able to run all of the tests in your testcase, since I do not have the Irix system libraries available, but I was able to reproduce the linker error message about undefined symbols and I have produced a tentative patch that might allow give you a working GNU linker. The patch does not implement all of the spec for OPTIONAL symbols. I hope that for now this will not be important. The patch also includes a modification to readelf so that it will display the OPTIONAL flag if it is defined in an Irix binary. You do not actually need this part of the patch in order to get a working linker, but I have included it since it is all part of the same problem. Cheers Nick
Created attachment 754 [details] Second attempt to handle OPTIONAL symbols
The testcase nwo runs fine with the patched ld: [michael@tharbad ot]$ make bu as -64 -o start.o start.s as -64 -o ot.o ot.s as -64 -o os.o os.s /usr/local/bin/ld -melf64bmip -o ot-opt-bu /usr/lib64/mips4/crt1.o ot.o os.o /usr/lib64/mips4/crtn.o -lc /usr/local/bin/ld -melf64bmip -o ot-noopt-bu /usr/lib64/mips4/crt1.o ot.o /usr/lib64/mips4/crtn.o -lc sed -e "s,/\* \(.weak.*\) \*/,\1," ot.s >otw.s as -64 -o otw.o otw.s /usr/local/bin/ld -melf64bmip -o otw-opt-bu /usr/lib64/mips4/crt1.o otw.o os.o /usr/lib64/mips4/crtn.o -lc /usr/local/bin/ld -melf64bmip -o otw-noopt-bu /usr/lib64/mips4/crt1.o otw.o /usr/lib64/mips4/crtn.o -lc [ -x ot-opt-bu ] && ./ot-opt-bu *** Error code 73 (bu21) (ignored) [ -x ot-noopt-bu ] && ./ot-noopt-bu *** Error code 255 (bu21) (ignored) [ -x otw-opt-bu ] && ./otw-opt-bu *** Error code 73 (bu21) (ignored) [ -x otw-noopt-bu ] && ./otw-noopt-bu *** Error code 255 (bu21) (ignored) Even the not-present-detection seems to work somehow (!?). Ahh, that may be because the optional symbols are actually resolved to __missing_function_ by *rld* not ld. But the original problem with libpthread remains: [michael@tharbad ~]$ cat t.c int main(void) { } [michael@tharbad ~]$ gcc -o t.o -c t.c [michael@tharbad ~]$ gcc -o t t.o -lpthread /usr/lib/../lib64/libpthread.so: undefined reference to `_mpi_sgi_init' collect2: ld returned 1 exit status The actual ld call is as follows: /usr/local/bin/ld -v -call_shared -init __gcc_init -fini __gcc_fini -melf64bmip -o t /usr/lib64/mips3/crt1.o /usr/local/gcc-4.0.1/lib/gcc/mips-sgi-irix6.5/4.0.1/64/irix-crti.o /usr/local/gcc-4.0.1/lib/gcc/mips-sgi-irix6.5/4.0.1/64/crtbegin.o -L/usr/local/gcc-4.0.1/lib/gcc/mips-sgi-irix6.5/4.0.1/64 -L/usr/local/gcc-4.0.1/lib/gcc/mips-sgi-irix6.5/4.0.1 -L/usr/local/gcc-4.0.1/lib/gcc/mips-sgi-irix6.5/4.0.1/../../../../lib64 -L/usr/local/gcc-4.0.1/lib/gcc/mips-sgi-irix6.5/4.0.1/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 t.o -lpthread -lgcc -L/usr/lib64/mips3 -L/usr/lib64 -lc -lgcc /usr/local/gcc-4.0.1/lib/gcc/mips-sgi-irix6.5/4.0.1/64/crtend.o /usr/local/gcc-4.0.1/lib/gcc/mips-sgi-irix6.5/4.0.1/64/irix-crtn.o /usr/lib64/mips3/crtn.o Is there a difference in treatment of object and *shared* object symbols?
Subject: Re: undefined reference to `_mpi_sgi_init' Hi Michael, > The testcase nwo runs fine with the patched ld: Great - I will check that patch in then as a first step in resolving this PR. > But the original problem with libpthread remains: > [michael@tharbad ~]$ gcc -o t t.o -lpthread > /usr/lib/../lib64/libpthread.so: undefined reference to `_mpi_sgi_init' Ho Hum. > Is there a difference in treatment of object and *shared* object symbols? Yes - they can be handled differently, and presumably they are being treated differently in this case. Can you investigate this part of the problem ? Basically you need to find where this undefined symbol is being detected. It will almost certainly be just before some code that calls: link_info->callbacks->undefined_symbol somewhere in the BFD library code. Alternatively if you make those Irix system files available to me, I can have a go - BUT ... I am about to go off and work at a client site for a month or so, so I will not be able to put as much time into binutils work. Cheers Nick
Created attachment 755 [details] new test case covering shared libraries containing optional symbols I've updated the test case to produce two shared libraries libos.so and libot.so. libos.so contains the variable os, libot.so the function ot() which reads the value of os if linked against libos and returns -1 if not, as before. There's a new object otm.o which contains a simple main function just calling ot() and returning its return value. Using this test case it can be confirmed that symbols in shared object files are indeed treated differently from optional symbols in normal object files.
Created attachment 756 [details] patch to make a mips-sgi-irix6.5 cross ld work for above test case The above test case works "fine" with a native mips-sgi-irix6.5 binutils ld on irix 6.5.28 in that ld will run and produce an "undefined reference to 'os'" error message. On Mac OS X 10.3 my cross ld gives an error message: ld -melf64bmip -rpath `pwd` -L`pwd` -o ot-noopt-bu start.o otm.o -lot ld: BFD 2.16.1 assertion fail elfxx-mips.c:5716 I circumvented this using the attached patch. I'm puzzled by the fact that it works with a native ld on irix, which is why I think it's some kind of platform specific or even optimization bug. It shouldn't really be an endianess bug since the MIPS R10000 as well as the PowerPC G4 are big endian by default. I haven't tested this on an Intel machine. Would this be worth its own PR?
Created attachment 757 [details] attempt to extend optional symbol support to shared libraries Hi Nick, using the above test case I tracked down the place in elflink.c where the symbol os is reported as undefined when localed in a shared library. The attached patch hacks elflink.c to check for STO_OPTIONAL in h->other. This makes the test case work with both native IRIX and Mac OS X cross binutils: [michael@tharbad ot2]$ make bu /home/michael/binutils-2.16.1/build/ld/ld-new -melf64bmip -rpath `pwd` -L`pwd` -o ot-noopt-bu /usr/lib64/mips4/crt1.o otm.o /usr/lib64/mips4/crtn.o -lot -lc /home/michael/binutils-2.16.1/build/ld/ld-new -melf64bmip -rpath `pwd` -L`pwd` -o otw-noopt-bu /usr/lib64/mips4/crt1.o otm.o /usr/lib64/mips4/crtn.o -lot -lc [ -x ot-opt-bu ] && ./ot-opt-bu *** Error code 73 (bu21) (ignored) [ -x ot-noopt-bu ] && ./ot-noopt-bu *** Error code 255 (bu21) (ignored) [ -x otw-opt-bu ] && ./otw-opt-bu *** Error code 73 (bu21) (ignored) [ -x otw-noopt-bu ] && ./otw-noopt-bu *** Error code 255 (bu21) (ignored) I'm not sure what other consequences just ignoring STO_OPTIONAL symbols in elflink.c has. And certainly the patch ignores all internal APIs regarding callbacks and format/platform abstraction. But it seems to be a step towards making it work [tm]. ;) Hope you have some more time to look into this.
Subject: Re: undefined reference to `_mpi_sgi_init' Hi Michael, > using the above test case I tracked down the place in elflink.c where the > symbol os is reported as undefined when localed in a shared library. The > attached patch hacks elflink.c to check for STO_OPTIONAL in h->other. This > makes the test case work with both native IRIX and Mac OS X cross binutils: Excellent! I am a little bit hesitant to apply your patch as it is however since it adds target specific code to a file that is meant to be generic. Could you investigate changing your patch so that it adds a new elf backend function which can be called when an undefined symbol is encountered and which allows individual backends to decide if the symbol can be ignored ? Cheers Nick
Created attachment 766 [details] generalise previous patch, depends on earlier MIPS-OPTIONAL patch Welcome back, Nick, > Excellent! I am a little bit hesitant to apply your patch as it is > however since it adds target specific code to a file that is meant to be > generic. Could you investigate changing your patch so that it adds a > new elf backend function which can be called when an undefined symbol is > encountered and which allows individual backends to decide if the symbol > can be ignored ? Mhmm, I actually wanted to avoid that since I don't have the slightest idea of how bfd works. But I gave it a try anyway. Find the result attached for piping to /dev/null. ;) BTW: I compiled lots of stuff on my Octane with the binutils patched with the earlier non-generic patch. All seems to work fine now, for example glib-2.8.3 with threading. make check completes 100% successful. Cheers, Micha
FYI I build a toolchain using gcc-4.0.2 and binutils-2.16.1 patched with MIPS_OPTIONAL.patch and the binutils-2.16.1-elflink-optional-2.patch. gcc was configured with the following options: --with-gnu-as --with-gnu-ld --disable-shared --enable-threads=posix --enable-libgcj --with-gmp=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5 --with-mpfr=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5 --enable-languages=c,ada,c++,f95,java,objc Using this toolchain I managed to compile the following packages: autoconf-2.13 autoconf-2.59 autogen-5.7.3 automake-1.9.6 bash-3.1 bison-2.1 bzip2-1.0.3 coreutils-5.93 db-3.3.11 db-4.3.28.NC dejagnu-1.4.4 diffutils-2.8.1 expat-1.95.8 expect-5.43 flex-2.5.4 gawk-3.1.4 gdbm-1.8.3 gettext-0.14.5 gmp-4.1.4 gperf-3.0.1 grep-2.5.1a guile-1.6.7 gzip-1.2.4a libtool-1.5.20 libxml2-2.6.22 m4-1.4.4 make-3.80 mpfr-2.2.0 ncurses-5.5 patch-2.5.4 pcre-6.3 perl-5.8.7 Python-2.3.5 Python-2.4.2 readline-5.1 sed-4.1.4 tar-1.15.1 tbcload tcl8.4.12 tetex-src-3.0 tk8.4.12 zlib-1.2.3 Did somebody else some tests using these binutils patches? Is there a chance that these patches will be applied? Rainer
Subject: Re: undefined reference to `_mpi_sgi_init' Hi Rainer, > Did somebody else some tests using these binutils patches? Not yet, but I am back at my normal workplace now, so this is on my list. > Is there a chance that these patches will be applied? Yup, in a couple of days probably. Sorry for the delay. Cheers Nick
Hi Micha, Sorry for the long delay in reviewing your latest patch. As it turns out it is fine (module a few formatting niggles) and so I have checked it in to the sources along with this ChangeLog entry. Cheers Nick bfd/ChangeLog PR 1150 * elf-bfd.h (struct elf_backend_data): New field 'elf_backend_ignore_undef_symbol'. * elfxx-target.h (elf_backend_ignore_undef_symbol): Define to NULL if not already defined. (elfNN_bed): Initialise the elf_backend_ignore_undef_symbol field. * elfxx-mips.c (_bfd_mips_elf_ignore_undef_symbol): New function. * elfxx-mips.h (elf_backend_ignore_undef_symbol): Define and prototype. * elflink.c (elf_link_output_extsym): Check elf_backend_ignore_undef_symbol before reporting an undefined symbol in a shared library.