RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
Hi Charles, (*) tentative because I can't actually test it myself against HEAD, given the pre-existing problem with binutils HEAD on pe386. The unwanted symbols, which this patch avoid, seems to be exported in some packages. When this patch is applied, perhaps it makes sense to update the following libs. dll count /bin/cygcrypto.dll 75 /bin/cygexslt-0.dll106 /bin/cygform6.dll 45 /bin/cyggdbm.dll 25 /bin/cyghistory5.dll 26 /bin/cygintl-1.dll 35 /bin/cygjbig1.dll 9 /bin/cygjpeg6b.dll 17 /bin/cygltdl-3.dll 31 /bin/cygmenu6.dll 34 /bin/cygncurses++6.dll254 /bin/cygncurses6.dll 74 /bin/cygpanel6.dll 14 /bin/cygpcre.dll 24 /bin/cygpcreposix.dll 26 /bin/cygpng2.dll 28 /bin/cygreadline5.dll 72 /bin/cygregex.dll 42 /bin/cygssl.dll200 /bin/cygtiff3.dll 65 /bin/cygxml2-2.dll 67 /bin/cygxslt-1.dll161 /bin/cygxsltbreakpoint-1.dll 9 /bin/cygz.dll 25 Regards Ralf
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
In theory, it looks good. However, have you tested the following: a) build a dll using an unmodified ld. b) build an app that uses that dll, and which accesses both a function export and a data export from the dll. c) rebuild the dll using your modified ld. d) does the app still work, without relinking? Because the patch does only affect generating import library, this condition is obsolate. A real test is relinking the app with an unmodified ld. I'll send a testcase protocol in the near furture. Regards Ralf
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
In theory, it looks good. However, have you tested the following:
a) build a dll using an unmodified ld.
ls /usr/i686-pc-cygwin/bin/ -l
lrwxrwxrwx1 1002 Kein 26 Apr 19 07:49 ar.exe -
/usr/bin/ar.exe
lrwxrwxrwx1 1002 Kein 26 Apr 19 07:49 as.exe -
/usr/bin/as.exe
lrwxrwxrwx1 1002 Kein 26 Apr 19 07:49 ld.exe -
/usr/bin/ld.exe
lrwxrwxrwx1 1002 Kein 26 Apr 19 07:49 nm.exe -
/usr/bin/nm.exe
lrwxrwxrwx1 1002 Kein 30 Apr 19 07:49 ranlib.exe -
/usr/bin/ranlib.exe
lrwxrwxrwx1 1002 Kein 29 Apr 19 07:49 strip.exe -
/usr/bin/strip.exe
$ cp /bin/ld.exe.2006 /bin/ld.exe
$ ld -v --help | head -1
GNU ld version 2.11.92 20011216
$ cat dll.cc
#include stdio.h
int var=0;
namespace A {
void printfunc(void){ printf(printfunc%04d called\n,0); }
}
$ cat dll.h
extern int var;
namespace A {
void printfunc(void);
}
#define vars() \
printf(v=%04d\n,var);\
#define funcs() \
A::printfunc();\
$ make dll.dll
gawk -f dll.awk dll.cc
g++ -c -o dll.o dll.cc
g++ --shared dll.o -o dll.dll -Wl,--out-implib,libdll.a
Creating library file: libdll.a
$ nm libdll.a
d11.o:
i .idata$4
i .idata$5
i .idata$7
I _dll_dll_iname
d00.o:
i .idata$2
i .idata$4
i .idata$5
I __head_dll_dll
U _dll_dll_iname
d10.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp__var
I __nm__var
d09.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp__printfunc__1Av
I __nm__printfunc__1Av
T _printfunc__1Av
d08.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__realloc
I __nm___nm__realloc
d07.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__printf
I __nm___nm__printf
d06.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__malloc
I __nm___nm__malloc
d05.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__free
I __nm___nm__free
d04.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__dll_dllcrt0
I __nm___nm__dll_dllcrt0
d03.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__cygwin_internal
I __nm___nm__cygwin_internal
d02.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__cygwin_detach_dll
I __nm___nm__cygwin_detach_dll
d01.o:
i .idata$4
i .idata$5
i .idata$6
i .idata$7
t .text
U __head_dll_dll
I __imp___nm__calloc
I __nm___nm__calloc
done
b) build an app that uses that dll, and which accesses both a function
export and a data export from the dll.
$ cat client.cc
#include stdio.h
#include dll.h
main()
{
funcs();
vars();
}
$ make client.exe
g++ -c -o client.o client.cc
g++ -o client.exe client.o -v -Wl,--enable-auto-import -L. -ldll
Warning: resolving _var by linking to __imp__var (auto-import)
$ ./client.exe
printfunc called
v=
c) rebuild the dll using your modified ld.
cp ~/src/sources.redhat.com/src/ld/ld-new /bin/ld.exe
$ ld -v --help | head -1
GNU ld version 2.12.90 20020425
$ rm dll.dll
habacker@BRAMSCHE ~/src/ld-contrib/ld-bugfix-test
$ make dll.dll
g++ --shared dll.o -o dll.dll -Wl,--out-implib,libdll.a
Creating library file: libdll.a
to verify that the patch does his work, compare with mentioned above nm list.
$ nm libdll.a
d03.o:
i .idata$4
i .idata$5
i .idata$7
I _dll_dll_iname
d00.o:
i .idata$2
i .idata$4
i .idata$5
I __head_dll_dll
U _dll_dll_iname
d02.o:
i .idata$4
i .idata$5
i
Re: cygwin ld import library issue fix (removing unused _nm_ symbols)
Ralf Habacker wrote:
b) build an app that uses that dll, and which accesses both a function
export and a data export from the dll.
$ cat client.cc
#include stdio.h
#include dll.h
main()
{
funcs();
vars();
}
Except that I'd access 'v' *directly* from client.cc; you're not
*really* accessing the variable yourself; you're calling a function in
the DLL which accesses the variable.
However
$ make client.exe
g++ -c -o client.o client.cc
g++ -o client.exe client.o -v -Wl,--enable-auto-import -L. -ldll
Warning: resolving _var by linking to __imp__var (auto-import)
^
shows that the linker IS able to resolve the reference (although why it
even tried to do so is another questions...)
c) rebuild the dll using your modified ld.
d) does the app still work, without relinking?
$ ./client
printfunc called
v=
Nice...
e) additional relink app with unmodified ld to see if old ld can handle this
import library
$ cp /bin/ld.exe.2001_10_03 /bin/ld.exe
$ rm client.exe
$ make client.exe
g++ -c -o client.o client.cc
g++ -o client.exe client.o -v -Wl,--enable-auto-import -L. -ldll
Warning: resolving _var by linking to __imp__var (auto-import)
^^
Again, it seems to resolve the v import.
$ ./client.exe
printfunc called
v=
But client doesn't really access the variable directly.
So this seems to work.
Cool.
--Chuck
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
Ralf Habacker
-Original Message-
From: Charles Wilson [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 27, 2002 6:55 PM
To: Ralf Habacker
Cc: Kde-Cygwin; Cygwin-Apps; Binutils
Subject: Re: cygwin ld import library issue fix (removing unused _nm_
symbols)
Ralf Habacker wrote:
b) build an app that uses that dll, and which accesses both a function
export and a data export from the dll.
$ cat client.cc
#include stdio.h
#include dll.h
main()
{
funcs();
vars();
}
Except that I'd access 'v' *directly* from client.cc; you're not
*really* accessing the variable yourself; you're calling a function in
the DLL which accesses the variable.
... and accessing var in client.cc
Do you have really read the dll.h ?
snip
#define vars() \
printf(v=%04d\n,var);\
snip ^^^
the vars macro is called in client.cc !!
Ralf
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
--- Ralf Habacker [EMAIL PROTECTED] wrote: (*) tentative because I can't actually test it myself against HEAD, given the pre-existing problem with binutils HEAD on pe386. I have tried,it works, Danny Smith seems to have fixed the bugs located in bfd. Alan Modra fixed it, not me. http://sources.redhat.com/ml/binutils/2002-04/msg00441.html Danny Ralf http://messenger.yahoo.com.au - Yahoo! Messenger - A great way to communicate long-distance for FREE!
Re: cygwin ld import library issue fix (removing unused _nm_ symbols)
--- Ralf Habacker [EMAIL PROTECTED] wrote: Hi,
this patch fixes an cygwin ld issue (GNU ld version 2.11.92 20011001) I've
encountered while analysing the runtime linking performance for kde.
Background:
The ld-auto-import stuff introduces additional symbols (_nm_...) in the
import
library which are only needed for data exports.
Unfortunally this symbols are generated for every export.
Additional ld rexports imported _nm_ symbols from other dlls, so one get
symbols like _nm___nm__scanf for example.
One can say this isn't a real problem and the answer is yes ... for little
dll's.
But if you look in the below mentioned import libraries, one can save about
30%
of the import libraries size.
For the kde 2.2.2 devel libs and base package this would save about 26MB.
And this seems to be a fact for applying this fix.
without patch
-rwxrwxrwx1 1002 Kein 3190016 Apr 20 19:12 libkdecore.dll.a
-rwxrwxrwx1 1002 Kein 7526 Apr 20 19:01 libkdefakes.dll.a
-rwxrwxrwx1 1002 Kein 5693370 Apr 20 01:16 libkdeui.dll.a
with patch
-rwxrwxrwx1 1002 Kein 2126660 Apr 25 10:48 libkdecore.dll.a
-rwxrwxrwx1 1002 Kein 1448 Apr 25 10:45 libkdefakes.dll.a
-rwxrwxrwx1 1002 Kein 3622512 Apr 25 11:06 libkdeui.dll.a
$ diff pe-dll.c.orig pe-dll.c -ubBp
--- pe-dll.c.orig Wed Apr 24 09:48:59 2002
+++ pe-dll.cThu Apr 25 08:33:08 2002
@@ -248,6 +250,8 @@ static autofilter_entry_type autofilter_
/* Do __imp_ explicitly to save time. */
{ __rtti_, 7 },
{ __builtin_, 10 },
+ // RH: prevent generating reimported functions
+ { _nm_, 4 },
/* Don't export symbols specifying internal DLL layout. */
{ _head_, 6 },
{ _fmode, 6 },
@@ -1789,6 +1793,8 @@ make_one (exp, parent)
quick_symbol (abfd, U (_imp__), exp-internal_name, , id5, BSF_GLOBAL,
0);
/* Symbol to reference ord/name of imported
symbol, used to implement auto-import. */
+ /* RH: only for auto-imported data */
+ if (exp-flag_data)
quick_symbol (abfd, U(_nm__), exp-internal_name, , id6, BSF_GLOBAL,
0);
if (pe_dll_compat_implib)
quick_symbol (abfd, U (__imp_), exp-internal_name, ,
Any comments ?
Regards
Ralf Habacker
Yes, this looks very nice, but does it works against current CVS? I hope you
can say yes.
Danny.
http://messenger.yahoo.com.au - Yahoo! Messenger
- A great way to communicate long-distance for FREE!
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
Hi Danny, Yes, this looks very nice, but does it works against current CVS? This patch is a minor change, which could be reviewed easy, but I have got trouble using the current cvs head (binutils 2-12.xx) release from sources.redhat.com. It produces undefined symbols compiling dll/apps and that means cygwin support seems to be broken. Because I hadn't enough time to check this, I installed the sources from the last official cygwin binutils release (GNU ld version 2.11.92 20011001) and have applied this patch. Ralf
Re: cygwin ld import library issue fix (removing unused _nm_ symbols)
On Thu, Apr 25, 2002 at 01:32:47PM +0200, Ralf Habacker wrote: Hi Danny, Yes, this looks very nice, but does it works against current CVS? This patch is a minor change, which could be reviewed easy, but I have got trouble using the current cvs head (binutils 2-12.xx) release from sources.redhat.com. It produces undefined symbols compiling dll/apps and that means cygwin support seems to be broken. Because I hadn't enough time to check this, I've taken a look on the cvs archive to verify this. Are I'm right using the cygnus_cvs_20020108_pre tag ? Why are you using a tag at all? Your patches should be against the binutils trunk. cgf
Re: cygwin ld import library issue fix (removing unused _nm_ symbols)
+ // RH: prevent generating reimported functions Do not use C++ style comments in C code. It is non-portable.
Re: cygwin ld import library issue fix (removing unused _nm_ symbols)
+ // RH: prevent generating reimported functions Do not use C++ style comments in C code. It is non-portable. Don't you mean C99 style comments? Would be portable if the world adopted a standard now 2 years old...
Re: cygwin ld import library issue fix (removing unused _nm_ symbols)
Don't you mean C99 style comments? If I had meant C99, I would have said C99. Would be portable if the world adopted a standard now 2 years old... You may dream all you like, but portable means works on all the systems we support. We cannot control the systems. We can control our sources. Portability precludes //-style comments in binutils.
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
Do not use C++ style comments in C code. It is non-portable.
This is an updated patch against the current cvs release and without c++
comments and a (I hope) propper changeLog entry.
2002-04-25 Ralf Habacker [EMAIL PROTECTED]
* pe-dll.cc (autofilter_symbolprefixlist): don't export
reimported functions.
(make_one): let create only _nm_.. for data symbols
Index: pe-dll.c
===
RCS file: /cvs/src/src/ld/pe-dll.c,v
retrieving revision 1.38
diff -u -3 -p -r1.38 pe-dll.c
--- pe-dll.c15 Feb 2002 02:11:05 - 1.38
+++ pe-dll.c25 Apr 2002 18:34:43 -
@@ -252,6 +252,8 @@ static autofilter_entry_type autofilter_
/* { __imp_, 6 }, */
/* Do __imp_ explicitly to save time. */
{ __rtti_, 7 },
+ /* Don't export reimported functions*/
+ { _nm_, 4 },
{ __builtin_, 10 },
/* Don't export symbols specifying internal DLL layout. */
{ _head_, 6 },
@@ -1793,8 +1795,11 @@ make_one (exp, parent)
quick_symbol (abfd, U (_head_), dll_symname, , UNDSEC, BSF_GLOBAL, 0);
quick_symbol (abfd, U (_imp__), exp-internal_name, , id5, BSF_GLOBAL,
0);
/* Symbol to reference ord/name of imported
- symbol, used to implement auto-import. */
- quick_symbol (abfd, U(_nm__), exp-internal_name, , id6, BSF_GLOBAL, 0);
+ symbol, used to implement auto-import.
+ (only for data symbols) */
+ if (exp-flag_data)
+quick_symbol (abfd, U(_nm__), exp-internal_name, , id6, BSF_GLOBAL,
0);
+
if (pe_dll_compat_implib)
quick_symbol (abfd, U (__imp_), exp-internal_name, ,
id5, BSF_GLOBAL, 0);
Re: cygwin ld import library issue fix (removing unused _nm_ symbols)
In theory, it looks good. However, have you tested the following:
a) build a dll using an unmodified ld.
b) build an app that uses that dll, and which accesses both a function
export and a data export from the dll.
c) rebuild the dll using your modified ld.
d) does the app still work, without relinking?
If not, then I can't accept this -- it would eventually break ALL
existing dynamically linked exe's.
--Chuck
Ralf Habacker wrote:
Do not use C++ style comments in C code. It is non-portable.
This is an updated patch against the current cvs release and without c++
comments and a (I hope) propper changeLog entry.
2002-04-25 Ralf Habacker [EMAIL PROTECTED]
* pe-dll.cc (autofilter_symbolprefixlist): don't export
reimported functions.
(make_one): let create only _nm_.. for data symbols
Index: pe-dll.c
===
RCS file: /cvs/src/src/ld/pe-dll.c,v
retrieving revision 1.38
diff -u -3 -p -r1.38 pe-dll.c
--- pe-dll.c15 Feb 2002 02:11:05 - 1.38
+++ pe-dll.c25 Apr 2002 18:34:43 -
@@ -252,6 +252,8 @@ static autofilter_entry_type autofilter_
/* { __imp_, 6 }, */
/* Do __imp_ explicitly to save time. */
{ __rtti_, 7 },
+ /* Don't export reimported functions*/
+ { _nm_, 4 },
{ __builtin_, 10 },
/* Don't export symbols specifying internal DLL layout. */
{ _head_, 6 },
@@ -1793,8 +1795,11 @@ make_one (exp, parent)
quick_symbol (abfd, U (_head_), dll_symname, , UNDSEC, BSF_GLOBAL, 0);
quick_symbol (abfd, U (_imp__), exp-internal_name, , id5, BSF_GLOBAL,
0);
/* Symbol to reference ord/name of imported
- symbol, used to implement auto-import. */
- quick_symbol (abfd, U(_nm__), exp-internal_name, , id6, BSF_GLOBAL, 0);
+ symbol, used to implement auto-import.
+ (only for data symbols) */
+ if (exp-flag_data)
+quick_symbol (abfd, U(_nm__), exp-internal_name, , id6, BSF_GLOBAL,
0);
+
if (pe_dll_compat_implib)
quick_symbol (abfd, U (__imp_), exp-internal_name, ,
id5, BSF_GLOBAL, 0);
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
On Thu, Apr 25, 2002 at 01:32:47PM +0200, Ralf Habacker wrote: Hi Danny, Yes, this looks very nice, but does it works against current CVS? This patch is a minor change, which could be reviewed easy, but I have got trouble using the current cvs head (binutils 2-12.xx) release from sources.redhat.com. It produces undefined symbols compiling dll/apps and that means cygwin support seems to be broken. Because I hadn't enough time to check this, I've taken a look on the cvs archive to verify this. Are I'm right using the cygnus_cvs_20020108_pre tag ? Why are you using a tag at all? Your patches should be against the binutils trunk. I have updated the patch. But the problem still is as I've said. The current ld cvs head release does not work !! I have build a simple lib and an app (without my patches) and the result is an undefined, either for functions or for auto-imported data. Test case is appended. Can anybody tell me which cvs version is the last stable ? I have tried to checkout binutils with date 2001/12/31, but got compiling errors. $ make dll.dll client.exe gawk -f dll.awk dll.cc g++ -c -o dll.o dll.cc g++ --shared dll.o -o dll.dll -Wl,--out-implib,libdll.a Creating library file: libdll.a g++ -c -o client.o client.cc g++ -o client.exe client.o -v -Wl,--enable-auto-import -L. -ldll #-ldll2 Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specs gcc version 2.95.3-5 (cygwin special) /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/collect2.exe -Bdynamic --dll-search-pre fix=cyg -o client.exe /usr/lib/crt0.o - L. -L/usr/local/lib -L/usr/lib -L/usr/lib/w32api -L/usr/lib/gcc-lib/i686-pc-cygw in/2.95.3-5 -L/usr/lib/gcc-lib/i686-pc-c ygwin/2.95.3-5/../../../../i686-pc-cygwin/lib client.o --enable-auto-import -ldll -lstdc++ -lgcc -lcygwin -luser32 -lker nel32 -ladvapi32 -lshell32 -lgcc client.o(.text+0x48):client.cc: undefined reference to `A::printfunc(void)' client.o(.text+0x4d):client.cc: undefined reference to `A::printfunc0001(void)' client.o(.text+0x52):client.cc: undefined reference to `A::printfunc0002(void)' client.o(.text+0x57):client.cc: undefined reference to `A::printfunc0003(void)' client.o(.text+0x5c):client.cc: undefined reference to `A::printfunc0004(void)' client.o(.text+0x64):client.cc: undefined reference to `var' client.o(.text+0x7a):client.cc: undefined reference to `var0001' client.o(.text+0x90):client.cc: undefined reference to `var0002' client.o(.text+0xa6):client.cc: undefined reference to `var0003' client.o(.text+0xbc):client.cc: undefined reference to `var0004' collect2: ld returned 1 exit status make: *** [client.exe] Error 1 client.tar.bz2 Description: Binary data
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
--- Ralf Habacker [EMAIL PROTECTED] wrote: Can anybody tell me which cvs version is the last stable ? I have tried to checkout binutils with date 2001/12/31, but got compiling errors. Compiling errors are fixed (was an overseen cvs conflict, but the problem still remains). So it seems to me, that the last official binutils release was the last stable release. Has noone checked the patches after the last official release ? Ralf ld was broken between 16 Dec (works) and 17 Dec (doesn't). The breakage was reported to binutils list in January. I think, the problem is with merging of sections in pe-dll.c in make_head() when making implib. Danny http://messenger.yahoo.com.au - Yahoo! Messenger - A great way to communicate long-distance for FREE!
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
* emultempl/pe.em (gld_${EMULATION_NAME}_place_orphan): Likewise.
Then this file could only be affected
When you take a look at the following changelog entry I assume, that this isn't
the problem, because there are only 4 changed lines, much more changes are
located in the bfd lib
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/ld/emultempl/pe.em?rev=1.57con
tent-type=text/x-cvsweb-markupcvsroot=src
Revision 1.57 / (download) - annotate - [select for diffs] , Mon Dec 17 00:40:53
2001 UTC (4 months, 1 week ago) by amodra
Branch: MAIN
Changes since 1.56: +4 -0 lines
Diff to previous 1.56 (colored)
hash bfd sections for fast lookup and create.
bfd/ChangeLog
* bfd.c (struct _bfd): Add section_htab, section_tail.
* libbfd-in.h (_bfd_delete_bfd): Declare.
(bfd_section_hash_newfunc): Declare.
* opncls.c (_bfd_new_bfd): Free memory on failure. Init
section_htab and section_tail.
(_bfd_delete_bfd): New function.
(bfd_openr): Use it.
(bfd_fdopenr): Likewise.
(bfd_openstreamr): Likewise.
(bfd_openw): Likewise.
(bfd_close): Likewise.
(bfd_close_all_done): Likewise.
(bfd_release): Comment.
* section.c (struct section_hash_entry): New.
(bfd_section_hash_newfunc): New function.
(section_hash_lookup): Define.
(bfd_section_init): New function, split out from
bfd_make_section_anyway.
(bfd_get_section_by_name): Lookup via hash table.
(bfd_get_unique_section_name): Likewise.
(bfd_make_section_old_way): Rewrite to use hash table.
(bfd_make_section_anyway): Likewise.
(bfd_make_section): Likewise. Return NULL for attempts to make
BFD_{ABS,COM,UND,IND}_SECTION_NAME.
(_bfd_strip_section_from_output): Adjust section_tail if needed.
* configure.in: Bump bfd version.
* configure: Regenerate.
* libbfd.h: Regenerate.
* bfd-in2.h: Regenerate.
ld/ChangeLog
* emultempl/elf32.em (gld${EMULATION_NAME}_place_orphan): Adjust
section_tail when fiddling with section list.
(gld${EMULATION_NAME}_list_options): Ensure sentences aren't
broken into separate strings to make translation easier.
* emultempl/mmo.em (mmo_place_orphan): Adjust section_tail when
fiddling with section list.
* emultempl/pe.em (gld_${EMULATION_NAME}_place_orphan): Likewise.
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
ld was broken between 16 Dec (works) and 17 Dec (doesn't). The breakage was reported to binutils list in January. I think, the problem is with merging of sections in pe-dll.c in make_head() when making implib. Another question: Does bfd have a debug mode or something else ? Ralf
RE: cygwin ld import library issue fix (removing unused _nm_ symbols)
--- Ralf Habacker [EMAIL PROTECTED] wrote: Can anybody tell me which cvs version is the last stable ? I have tried to checkout binutils with date 2001/12/31, but got compiling errors. Compiling errors are fixed (was an overseen cvs conflict, but the problem still remains). So it seems to me, that the last official binutils release was the last stable release. Has noone checked the patches after the last official release ? Ralf ld was broken between 16 Dec (works) and 17 Dec (doesn't). The breakage was reported to binutils list in January. I think, the problem is with merging of sections in pe-dll.c in make_head() when making implib. Your right, I have compared the implib and in 3,4,7,8 (see below) the symtable is missing. funcs linking dll app 1 old old - no problems 2 old new - no problems 3 new old - undefined reference error 4 new new - undefined reference error auto-imported data linking dll app 5 old old - no problems 6 old new - BFD 2.12.90 20020425 internal error, 7 new old - undefined reference error 8 new new - undefined reference error
Re: cygwin ld import library issue fix (removing unused _nm_ symbols)
You may dream all you like, but portable means works on all the systems we support. We cannot control the systems. We can control our sources. Portability precludes //-style comments in binutils. Well - personally I thought you had gcc to support all your platforms, which for ages has supported either style of comment... there's only a few relics I've run across which were barely even functional as compilers that didn't support it :)
Re: cygwin ld import library issue fix (removing unused _nm_ symbols)
Well - personally I thought you had gcc to support all your platforms, which for ages has supported either style of comment... there's only a few relics I've run across which were barely even functional as compilers that didn't support it :) gcc and binutils are the two packages that are at the highest portability levels. Other packages may choose to require those two be ported first. Binutils does not require that gcc be ported before it. In fact, gcc sometimes requires that binutils be ported first, otherwise it cannot build libgcc.a
