Bugs item #815021, was opened at 2003-09-30 12:46
Message generated for change (Comment added) made by papadopo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=815021&group_id=2435
Category: gcc
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Dimitri Papadopoulos (papadopo)
Assigned to: Danny Smith (dannysmith)
Summary: -Wl,--allow-shlib-undefined doesn't seem to work
Initial Comment:
Hi,
The --allow-shlib-undefined option doesn't seem to
allow undefined symbols in DLLs as advertized.
To reproduce this:
$ cat foo.c
#include "foo.h"
void toto() {
}
$
$ gcc -shared -o foo.dll foo.c
$
$ cat bar.c
#include "bar.h"
#include "foo.h"
void bar() {
foo();
}
$
$ gcc -shared -o bar.dll bar.c
C:/DOCUME~1/PAPADO~1.POB/LOCALS~1/Temp/ccspbaaa.o(.text+0x7):bar.c:
undefined reference to `foo'
$
So far so good. There's indeed an undefined reference.
Now try --allow-shlib-undefined to allow for these
undefined references:
$ gcc -shared -Wl,--allow-shlib-undefined -o bar.dll bar.c
C:/DOCUME~1/PAPADO~1.POB/LOCALS~1/Temp/ccspbaaa.o(.text+0x7):bar.c:
undefined reference to `foo'
$
I'm filing this as a gcc issue because callling ld
directly does work:
$ ld -r -o bar.dll bar.o
$ ld -r --allow-shlib-undefined -o bar.dll bar.o
$
----------------------------------------------------------------------
>Comment By: Dimitri Papadopoulos (papadopo)
Date: 2003-10-03 13:43
Message:
Logged In: YES
user_id=52414
OK, I understand now. Thank you for taking the time to explain.
Shouldn't the --allow-shlib-undefined option flag be
disabled on Windows then?
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2003-09-30 22:37
Message:
Logged In: YES
user_id=11494
DLL's are shared executables - with own 'main' entry point -
and like other executables do not allow undefined symbols.
This is not a mingw specific bug. It is a property of pe DLL's.
Danny
----------------------------------------------------------------------
Comment By: Dimitri Papadopoulos (papadopo)
Date: 2003-09-30 14:45
Message:
Logged In: YES
user_id=52414
The documentation for --allow-shlib-undefined reads:
Allow undefined symbols in shared objects even when
--no-undefined is set. The net result will be that undefined
symbols in regular objects will still trigger an error, but
undefined symbols in shared objects will be ignored. The
implementation of no_undefined makes the assumption that the
runtime linker will choke on undefined symbols. However
there is at least one system (BeOS) where undefined symbols
in shared libraries is normal since the kernel patches them
at load time to select which function is most appropriate
for the current architecture. I.E. dynamically select an
appropriate memset function. Apparently it is also normal
for HPPA shared libraries to have undefined symbols.
Isn't a DLL some sort of shared object? I'm not familiar
with the distinction that can be made between a shared
object like libfoo.so on POSIX machines and DLLs on Windows.
The context is that we're trying to build 3rd party Python
plugins. Python plugins are supposed to be linked with
PYTHON23.LIB, but this doesn't work a PYTHON.LIB was built
with Visual C++. We thought that we could use
--allow-shlib-undefined to build th eplugins with missing
symbols and find a solution later on. Like providing a DLL
with missing symbols at run-time.
Is this limitation with undefined symbols specific to MinGW?
Is it a general limitation of DLLs?
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2003-09-30 13:39
Message:
Logged In: YES
user_id=11494
Dll's do not allow undefined symbols. If someone is
advertising that --allow-shlib-undefined works for dll's, the
advertising is wrong.
ld -r -obar.dll bar.o does not produce a dll, it produces
another object file, but one with an unusual suffix.
Danny
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=815021&group_id=2435
|
