| delorie.com/archives/browse.cgi | search |
Christopher Faylor wrote:
> On Wed, Mar 25, 2009 at 12:49:36PM +0000, Dave Korn wrote:
>> So the linker is DTRT, the problem has always existed but been masked by the
>> fact that nothing between -lm and -lcygwin used to import anything, the
>> problem has arisen now because now that does happen, and the solution is to
>> mung the symbols in the import top/tail sections in libm so that libm and
>> libcygwin both each add a complete import table entry of their own (there's no
>> problem having two import tables against the same DLL). Once I've figured out
>> how that perl script works, I'll be able to suggest a patch.
>
> Don't bother. I'll look into it.
Thanks. As an experiment I tried adding (just after the line "0 while
s/$libdllname/$libname/sog;")
my $orig_iname="_cygwin1_dll_iname";
my $new_iname="_libm_dll_iname";
my $inamepad = length($orig_iname) - length($new_iname);
die "$0: library name too long (" . length($new_iname) . ")\n" if $inamepad < 0;
$new_iname .= "\0" x $inamepad;
0 while s/$orig_iname/$new_iname/sog;
... and although it produced a libm.a with the symbols I was hoping to see,
there's something wrong as the reference to _pow in zsh's math.o that was
previously pulling in libm.a(d0001286.o) fails to pull in anything from a libm
built with the above. Didn't get as far as figuring out what I did wrong yet,
but if you're looking after it I'll get on with GCC stuff.
cheers,
DaveK
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |