Mail Archives: cygwin/2000/07/04/22:41:19
Chris Faylor wrote:
>
> On Tue, Jul 04, 2000 at 10:08:31PM -0400, Charles Wilson wrote:
> >Well, he seems to have submitted it to the main binutils list
> >(http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00538.html). But, I
> >can't seem to find any evidence that it was actually committed in the
> >main binutils.
> >
> >Is it possible to include Mumit's patch, and the one posted by Eric
> >Fifer a few days ago, and release another version of cygwin-binutils (or
> >push those two patches into the main binutils, since you're releasing
> >out of sourceware)? I will try to sync up Mumit's patch with the
> >20000625 source code tonight...
>
> It's possible. Maybe DJ will even be able to commit Mumit's change.
>
> I don't know what Eric Fifer's change was but if it is the dllwrap
> fix, it's already in cvs.
Yes, you are correct. I just checked the cvsweb interface and Eric's
change had been committed.
The binutils-20000625-src.tar.gz is not *strictly* a pure
out-of-sourceware release. The cvs shows that only the first part of my
changes to emultempl/pe.em are there, but all of my changes to that file
appear in the cygwin-specific tarball.
So, the current cvs dynamic lib search order is:
foo.dll
libfoo.dll
The cygwin tarball dynamic lib search order is:
libfoo.dll.a
foo.dll.a
libfoo.dll
foo.dll
Both versions fall back to libfoo.a if the 'dynamic' versions are not
found.
I'll whip up two patches tonight, then: one suitable for pushing my
changes into cvs, and the other for pushing Mumit's changes into cvs.
However, I am not sure that my more recent changes *should* be pushed
onto the non-cygwin community just yet; as Eric has pointed out, the new
search order can cause (fixable) problems when building some packages.
Basically, if you build package X that creates a dll as well as
executables you can run into breakages. Suppose package X creates
libfoo.dll and libfoo.a (an import lib, named according to the old
scheme), and bar.exe (which depends on libfoo.dll). Then, when building
bar.exe, the linker finds libfoo.dll instead of libfoo.a. Ordinarily,
this shouldn't cause a problem, although it is unexpected.
This problem is avoided when building package Y that depends on
libfoo.dll, because libfoo.dll is in some /bin directory (NOT in the
library path) and all ld can find is libfoo.a in the /lib directory.
But, when building package X, everything is right there in the source
directory, and not neatly placed into the /bin /lib trees. This can be
fixed, of course, -- package by package -- by changing the dlltool
commands in the packages' makefiles so that the import lib is named
libfoo.dll.a instead of libfoo.a.
I've pasted part of a message from Eric detailing a case where the new
search order (that is, the
libfoo.dll.a-foo.dll.a-libfoo.dll-foo.dll/libfoo.a search order) causes
problems because of differences between the dll and the import lib, and
the dll is found (and linked against) first.
The workaround, of course, is to fix the dlltool command so that the
import lib is called 'libperl5_6_0.dll.a'. We can deal with these issues
in the cygwin community, but I don't think it's a good idea to
inconvenience the rest of the pei386 folks with these most recent
changes just yet.
--Chuck
> I just installed the latest gcc/binutils, and because
> it is an old habit, tried to build Perl.
>
> The make fails at the first attempt to link against
> the recently built libperl5_6_0.{a,dll}:
>
> perlmain.c:42: undefined reference to `_imp__PL_do_undump'
> ...
> ext/DynaLoader/dlutils.c:42: undefined reference to `_imp__PL_stack_sp'
> ...
>
> All the symbols that are not found are exported data.
>
> Based on your comments, one of the recent changes was
> to link directly against a .dll instead of the import
> library .a. However, exported data (as opposed to
> functions) is not the same in a .dll and a .a:
>
> exported data:
> nm libperl5_6_0.a | grep PL_stack_sp
> 00000000 ? __imp__PL_stack_sp
>
> nm libperl5_6_0.dll | grep PL_stack_sp
> 68865160 B _PL_stack_sp
>
> exported function:
> nm libperl5_6_0.a | grep perl_construct
> 00000000 ? __imp__perl_construct
> 00000000 T _perl_construct
>
> nm libperl5_6_0.dll | grep perl_construct
> 687c1088 T _perl_construct
>
> and in the .o's:
> nm perlmain.o
> U __imp__PL_perl_destruct_level
> U _perl_construct
>
> If I force linking against the .a (-static) things seem
> to work fine.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -