Bug 1150 - undefined reference to `_mpi_sgi_init'
Summary: undefined reference to `_mpi_sgi_init'
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.16
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
: 1151 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-08-02 13:40 UTC by Andreas Pfeil
Modified: 2005-12-23 12:28 UTC (History)
2 users (show)

See Also:
Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
Build: mips-sgi-irix6.5
Last reconfirmed:


Attachments
attempt to ignore OPTIONAL symbols (423 bytes, patch)
2005-11-09 16:25 UTC, Nick Clifton
Details | Diff
testcase for optional symbols (8.34 KB, application/octet-stream)
2005-11-09 21:16 UTC, Michael Weiser
Details
Second attempt to handle OPTIONAL symbols (2.17 KB, patch)
2005-11-10 12:51 UTC, Nick Clifton
Details | Diff
new test case covering shared libraries containing optional symbols (15.21 KB, application/octet-stream)
2005-11-13 17:41 UTC, Michael Weiser
Details
patch to make a mips-sgi-irix6.5 cross ld work for above test case (279 bytes, patch)
2005-11-13 17:49 UTC, Michael Weiser
Details | Diff
attempt to extend optional symbol support to shared libraries (395 bytes, patch)
2005-11-13 18:01 UTC, Michael Weiser
Details | Diff
generalise previous patch, depends on earlier MIPS-OPTIONAL patch (1.47 KB, patch)
2005-11-23 21:32 UTC, Michael Weiser
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Pfeil 2005-08-02 13:40:53 UTC
-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
Comment 1 H.J. Lu 2005-08-07 13:57:50 UTC
*** Bug 1151 has been marked as a duplicate of this bug. ***
Comment 2 Andreas Pfeil 2005-10-06 22:43:34 UTC
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 !

Comment 3 Michael Weiser 2005-11-06 19:20:33 UTC
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.
Comment 4 Nick Clifton 2005-11-08 15:04:13 UTC
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


Comment 5 Michael Weiser 2005-11-09 13:24:59 UTC
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.
Comment 6 Nick Clifton 2005-11-09 16:24:40 UTC
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


Comment 7 Nick Clifton 2005-11-09 16:25:25 UTC
Created attachment 752 [details]
attempt to ignore OPTIONAL symbols
Comment 8 Michael Weiser 2005-11-09 21:16:19 UTC
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.
Comment 9 Michael Weiser 2005-11-09 21:29:16 UTC
Sorry, the attachment lost its name: it's a gzipped tarball (ot.tar.gz).
Comment 10 Nick Clifton 2005-11-10 11:45:25 UTC
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

Comment 11 Nick Clifton 2005-11-10 12:51:26 UTC
Created attachment 754 [details]
Second attempt to handle OPTIONAL symbols
Comment 12 Michael Weiser 2005-11-10 18:57:40 UTC
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?
Comment 13 Nick Clifton 2005-11-11 11:21:57 UTC
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


Comment 14 Michael Weiser 2005-11-13 17:41:46 UTC
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.
Comment 15 Michael Weiser 2005-11-13 17:49:44 UTC
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?
Comment 16 Michael Weiser 2005-11-13 18:01:44 UTC
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.
Comment 17 Nick Clifton 2005-11-21 18:30:05 UTC
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




Comment 18 Michael Weiser 2005-11-23 21:32:18 UTC
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
Comment 19 Rainer Emrich 2005-12-21 16:32:29 UTC
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 
Comment 20 Nick Clifton 2005-12-22 17:46:17 UTC
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


Comment 21 Nick Clifton 2005-12-23 12:28:19 UTC
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.