Testers needed:
Ok, the first build of the new location setup.exe is available at: http://www.cygwin.com/setup-snapshots/setup-newlocation.exe. Please report any aberrant behaviour ASAP. "Works for me" :}. Rob
RE: setup changes to build standalone
> -Original Message- > From: Robert Collins > Sent: Friday, April 26, 2002 3:28 PM > To: Robert Collins; Cygwin-Apps > Subject: RE: setup changes to build standalone > > > > > > -Original Message- > > From: Robert Collins > > Sent: Friday, April 26, 2002 1:03 PM > > To: Cygwin-Apps > > Subject: setup changes to build standalone > > > > > > To build setup we need: > > a mingw bz2lib > > a mingw zlib > and a mingw getopt. For now I'm putting this in the setup > directory, but I'll almost certainly bundle it with > libgetopt++ (as no symbols from it are needed by the setup sources). sigh. And /src/winsup/cygwin/include/cygwin/version.h and /src/winsup/cygwin/include/sys/mount.h. For starters I'm just absorbing the content (only mount.cc needs them). However I think we should look at either a) having a mingw library for manipulating cygwin mount points officially available or b) having setup.exe call cygwin's mount.exe to setup the mount points in the first place, rather than setup being tightly linked to cygwin's registry format. c) some variation on the above themes. d) a --with-cygwin-headers=/path/to/headers and in mount.cc pickup the needed headers. Rob
RE: setup changes to build standalone
> -Original Message- > From: Robert Collins > Sent: Friday, April 26, 2002 1:03 PM > To: Cygwin-Apps > Subject: setup changes to build standalone > > > To build setup we need: > a mingw bz2lib > a mingw zlib and a mingw getopt. For now I'm putting this in the setup directory, but I'll almost certainly bundle it with libgetopt++ (as no symbols from it are needed by the setup sources). Rob
RE: setup changes to build standalone
> -Original Message-
> From: Charles Wilson [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 26, 2002 2:12 PM
> https://sourceforge.net/projects/mingwrep/
Thanks.
> >>I wonder if we need a "mingw-libs" package.
> >>
> >
> > Yes, please, please, yes. I would really really love it if
> some of the
> > common libs (zlib, bz2lib, stdc++) where available in a setup.exe
> > installable pacakge.
>
>
> Yes, I like this too -- but I'm nervous about it growing ridiculously
> large. What if (eventually) setup.ini turns into XML? Do we put a
> mingw build of libxml into 'mingw-libs'? How far does this go?
> (visions of full{mingw}.exe)
glib + foo + bar + ...
If this sort of expansion were to occur, I'd suggest we take the
split-setup option and have a bootstrapping setup that is essentially
what we have today, but is only run once - ever. Then after that a
maintenance setup that is able to use cygwin linked tools.
> OTOH, we've already discussed (and discarded, thank g-d) the idea of
> (for instance) the zlib maintainer providing both a
> cygwin-setup-installable zlib package (/usr/bin/cygz.dll,
> /usr/lib/libz.[dll|a]) and a cygwin-setup-installable
> mingw-zlib package
> (/usr/bin/mgwz.dll, /usr/lib/mingw/libz.[dll|a]). Ditto
> bzip2, libxml,
> ... we are not a mingw-porting factory.
Agreed.
> whatever happened to the idea of an official cygwin package, that
> contained a true cygwin-host, mingw-target cross compiler? Didn't
> somebody or other volunteer to provide that?
I recall Danny talking about a gcc v 3.1 for April, but I'm not sure if
he meant as a cygwin package or as something else...
> > It really depends on what you want to do. Some stuff it does
> > spectalularly well, some things it has trouble with. With the 'cross
> > compiling but not' approach, it would almost certainly have
> some trouble
> > :}.
>
> see above, true cross compiler...
Yup. In fact gcc -mno-cygwin is close enough that automake won't be
confused... as long as it's told --host= :}.
Rob
RE: setup changes to build standalone
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 2:07 PM > To: [EMAIL PROTECTED] > Subject: Re: setup changes to build standalone > > > On Fri, Apr 26, 2002 at 01:44:32PM +1000, Robert Collins wrote: > >> 2) The above won't work in a cross build environment. You > could say > >>CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess. > > > >for cross compiles: > >../setup/configure --host=i686-pc-mingw32 --build-i686-pc-linux > >should do it (assuming a mingw32 cross compiler is present), or a > >combination using the CC string you have above with the > mingw host will > >work too. > > Assuming you have a mingw cross compiler is what I was trying > to avoid. For this purpose a 'gcc -mno-cygwin' compiler > should work fine. > > I think the use of CC='i686-pc-cygwin-gcc -mno-cygwin' should > work everywhere though. Cool. No issues there. Rob
RE: setup changes to build standalone
> A second issue is that I cannot get configure to play nice in the new > location without updating to 2.5x. That doesn't concern me, does it > concern anyone else? Not me. > On a separate but related topic, I'd like to automakeise (is that a > word) setup - if there are no objections from the other contributors. No, on the contrary I think that's a great idea. Raw Makefile.in's scare the hell out of me. ;-) -- Gary R. Van Sickle Brewer. Patriot.
Re: setup changes to build standalone
Robert Collins wrote:
> Yes. I even documented all this some time back on
> http://www.cygwin.com/ml/cygwin-apps/2001-11/msg00634.html, but
> predicatably enough, no patches where forthcoming. Probably due to the
> complete lack of a prebuilt bz2lib for mingw (that my cursory searches
> have looked for).
https://sourceforge.net/projects/mingwrep/
>>I wonder if we need a "mingw-libs" package.
>>
>
> Yes, please, please, yes. I would really really love it if some of the
> common libs (zlib, bz2lib, stdc++) where available in a setup.exe
> installable pacakge.
Yes, I like this too -- but I'm nervous about it growing ridiculously
large. What if (eventually) setup.ini turns into XML? Do we put a
mingw build of libxml into 'mingw-libs'? How far does this go?
(visions of full{mingw}.exe)
OTOH, we've already discussed (and discarded, thank g-d) the idea of
(for instance) the zlib maintainer providing both a
cygwin-setup-installable zlib package (/usr/bin/cygz.dll,
/usr/lib/libz.[dll|a]) and a cygwin-setup-installable mingw-zlib package
(/usr/bin/mgwz.dll, /usr/lib/mingw/libz.[dll|a]). Ditto bzip2, libxml,
... we are not a mingw-porting factory.
>>2) The above won't work in a cross build environment. You could say
>> CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess.
> for cross compiles:
> ../setup/configure --host=i686-pc-mingw32 --build-i686-pc-linux
> should do it (assuming a mingw32 cross compiler is present), or a
> combination using the CC string you have above with the mingw host will
> work too.
whatever happened to the idea of an official cygwin package, that
contained a true cygwin-host, mingw-target cross compiler? Didn't
somebody or other volunteer to provide that?
(Granted, we still need 'cygwin-gcc -mno-cygwin' for the "self-hosting"
feature of cygwin1.dll, but there's no real need to *require* cygwin-gcc
-mno-cygwin for setup.exe, now that setup has been moved out of the
winsup tree)
>>anything that is non-simple. I haven't looked at it in a
>>while, though, so maybe things have changed.
>>
>
> It really depends on what you want to do. Some stuff it does
> spectalularly well, some things it has trouble with. With the 'cross
> compiling but not' approach, it would almost certainly have some trouble
> :}.
see above, true cross compiler...
--Chuck
Re: setup changes to build standalone
On Fri, Apr 26, 2002 at 01:44:32PM +1000, Robert Collins wrote: >> 2) The above won't work in a cross build environment. You could say >>CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess. > >for cross compiles: >../setup/configure --host=i686-pc-mingw32 --build-i686-pc-linux >should do it (assuming a mingw32 cross compiler is present), or a >combination using the CC string you have above with the mingw host will >work too. Assuming you have a mingw cross compiler is what I was trying to avoid. For this purpose a 'gcc -mno-cygwin' compiler should work fine. I think the use of CC='i686-pc-cygwin-gcc -mno-cygwin' should work everywhere though. cgf
RE: setup changes to build standalone
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 1:19 PM > >So, > >I've made a copy of bz2lib from src/winsup/bz2lib to set/bz2lib, and > >adjusted accordingly. > > Ack. Duplication. Duplication bad. Yup. > Here was a good reason not to move cinstall. Sigh. Yes. I even documented all this some time back on http://www.cygwin.com/ml/cygwin-apps/2001-11/msg00634.html, but predicatably enough, no patches where forthcoming. Probably due to the complete lack of a prebuilt bz2lib for mingw (that my cursory searches have looked for). > I can't think of any way around this, though. Even if we say > "You must have a mingw version of libbz2.a available" that > will screw up my need for this library in winsup. > > I wonder if we need a "mingw-libs" package. Yes, please, please, yes. I would really really love it if some of the common libs (zlib, bz2lib, stdc++) where available in a setup.exe installable pacakge. > 1) Why the --host=? So that you'll be able to use a mingw version of >everything? Yes. It gets rid of the need for mingw_foo in the make files, and makes it explicit that we are cross compiling. > 2) The above won't work in a cross build environment. You could say >CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess. for cross compiles: ../setup/configure --host=i686-pc-mingw32 --build-i686-pc-linux should do it (assuming a mingw32 cross compiler is present), or a combination using the CC string you have above with the mingw host will work too. > I think you should just check it in and tweak things in cvs > rather than post a patch. It's not going to impact anyone > but a tiny handful of people if you use cvs but it will > impact a much larger audience if you send out patches. Ok, will do. > anything that is non-simple. I haven't looked at it in a > while, though, so maybe things have changed. It really depends on what you want to do. Some stuff it does spectalularly well, some things it has trouble with. With the 'cross compiling but not' approach, it would almost certainly have some trouble :}. Rob
Re: setup changes to build standalone
On Fri, Apr 26, 2002 at 01:03:05PM +1000, Robert Collins wrote: >To build setup we need: >a mingw bz2lib >a mingw zlib >w32api >in the future (soon I hope): >a mingw libstdc++ (and any dependencies it has). > >So, >I've made a copy of bz2lib from src/winsup/bz2lib to set/bz2lib, and >adjusted accordingly. Ack. Duplication. Duplication bad. Here was a good reason not to move cinstall. Sigh. I can't think of any way around this, though. Even if we say "You must have a mingw version of libbz2.a available" that will screw up my need for this library in winsup. I wonder if we need a "mingw-libs" package. >A second issue is that I cannot get configure to play nice in the new >location without updating to 2.5x. That doesn't concern me, does it >concern anyone else? Nope. >The configure line to prepare a website version of setup will be: >../setup/configure' --host=i686-pc-mingw32 --build=i686-pc-cygwin >'CC=gcc -mno-cygwin' 'CXX=g++ -mno-cygwin'. > >It should configure and build a cygwin1.dll linked version quite happily >if the --host parameter is left off. That may also be useful for test >builds and the like, and also for building command line mirroring tools >etc etc. 1) Why the --host=? So that you'll be able to use a mingw version of everything? 2) The above won't work in a cross build environment. You could say CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess. >I'll post a patch (probably up on sources.redhat.com/cygwin-apps/setup) >when I've got everything ready. (It's gonna be big (at least the size of >bz2lib :}) or I'd just drop it here). Then if a couple of folk have >success with it, I'll check it in. > >Any comments, peanuts, etc? I think you should just check it in and tweak things in cvs rather than post a patch. It's not going to impact anyone but a tiny handful of people if you use cvs but it will impact a much larger audience if you send out patches. >On a separate but related topic, I'd like to automakeise (is that a >word) setup - if there are no objections from the other contributors. >I'll do this as a separate commit, that is if noone has serious issues >with it. I actually started doing this when the cinstall directory was first introduced then realized, as I always do, that I hate automake. For me, it requires too much pain to get it to do anything that is non-simple. I haven't looked at it in a while, though, so maybe things have changed. Nevertheless, I have no objections to this. cgf
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
setup changes to build standalone
To build setup we need: a mingw bz2lib a mingw zlib w32api in the future (soon I hope): a mingw libstdc++ (and any dependencies it has). So, I've made a copy of bz2lib from src/winsup/bz2lib to set/bz2lib, and adjusted accordingly. A second issue is that I cannot get configure to play nice in the new location without updating to 2.5x. That doesn't concern me, does it concern anyone else? The configure line to prepare a website version of setup will be: ../setup/configure' --host=i686-pc-mingw32 --build=i686-pc-cygwin 'CC=gcc -mno-cygwin' 'CXX=g++ -mno-cygwin'. It should configure and build a cygwin1.dll linked version quite happily if the --host parameter is left off. That may also be useful for test builds and the like, and also for building command line mirroring tools etc etc. I'll post a patch (probably up on sources.redhat.com/cygwin-apps/setup) when I've got everything ready. (It's gonna be big (at least the size of bz2lib :}) or I'd just drop it here). Then if a couple of folk have success with it, I'll check it in. Any comments, peanuts, etc? On a separate but related topic, I'd like to automakeise (is that a word) setup - if there are no objections from the other contributors. I'll do this as a separate commit, that is if noone has serious issues with it. Rob
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 :)
setup aka cinstall location changed
This is an email for the archives... The location of the cygwin 'setup.exe' aka cinstall sources, has moved. The old location was /cvs/src/winsup/cinstall, the new location is /cvs/cygwin-apps/setup. The HEAD branch will be fixed shortly to compile outside the winsup tree. The setup200202 and older tags WILL NOT be updated. To build or compile those branches, place them in the winsup/cinstall location of your local cygwin src tree, and compile from there. Cheers, Rob
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: cinstall location
On Fri, Apr 26, 2002 at 08:01:46AM +1000, Robert Collins wrote: > > >> -Original Message- >> From: Christopher Faylor [mailto:[EMAIL PROTECTED]] >> Sent: Friday, April 26, 2002 1:42 AM >> To: [EMAIL PROTECTED] >> Subject: Re: cinstall location >> >> >> On Fri, Apr 26, 2002 at 01:32:08AM +1000, Robert Collins wrote: >> >sometime ago in a conversation about cinstall and the >> all-in-one setup >> >the topic of cinstall's location was rasied. At that point I >> didn't see >> >any need to move cinstall but I'd actually like to see >> it moved to >> >the cygwin-apps repository now. >> > >> >Why? >> >So that we can add a build dependency on a mingw libstdc++, >> and be done >> >with reinventing multiple wheels. >> > >> >I think that while moving won't be trauma-less, it will >> result in more >> >rapid development, and that can only be a good thing. It >> will also make >> >having a cinstall -src tarball easier, and the cygwin src snapshots >> >smaller. >> > >> >It's not intended to lessen the link between cinstall and cygwin at >> >all, rather to make building it easier. >> > >> >What do you think? >> >> I have no problems moving it. It never really fit into the >> winsup hierarchy. I put it there because I didn't want to >> make a new upper level directory on src and there was no >> cygwin-apps at the time. >> >> Let's rename the directory to 'setup', though. >> >> FWIW, I think I will physically move the cvs directory to a >> new location, wiping out all hints of cinstall from winsup. > >Yeah, I was going to suggest we do something like that. I've copied it >over to /cvs/cygwin-apps/setup, chowned it to be owned by cygwin-apps, >and test checking out the setup200202 branch - all of which worked fine. > > >So... want me to remove the (now obsolete) cinstall directory, or would >you like to do the honours? I've removed it. cgf
Re: Question about DOS text file.
On Thu, Apr 25, 2002 at 01:59:57PM -0700, Bernard Chow wrote: >The GCC version 2.95.3-5 come with cygwin version 1.3.10 as a package can >compile C source file with DOS end-of-line character. However, the GCC >built by myself can not compile DOS C file correctly. Please read the description for this mailing list at http://cygwin.com/lists.html. This is off-topic here. cgf
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: cinstall location
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 1:42 AM > To: [EMAIL PROTECTED] > Subject: Re: cinstall location > > > On Fri, Apr 26, 2002 at 01:32:08AM +1000, Robert Collins wrote: > > sometime ago in a conversation about cinstall and the > all-in-one setup > >the topic of cinstall's location was rasied. At that point I > didn't see > >any need to move cinstall but I'd actually like to see > it moved to > >the cygwin-apps repository now. > > > >Why? > >So that we can add a build dependency on a mingw libstdc++, > and be done > >with reinventing multiple wheels. > > > >I think that while moving won't be trauma-less, it will > result in more > >rapid development, and that can only be a good thing. It > will also make > >having a cinstall -src tarball easier, and the cygwin src snapshots > >smaller. > > > >It's not intended to lessen the link between cinstall and cygwin at > >all, rather to make building it easier. > > > >What do you think? > > I have no problems moving it. It never really fit into the > winsup hierarchy. I put it there because I didn't want to > make a new upper level directory on src and there was no > cygwin-apps at the time. > > Let's rename the directory to 'setup', though. > > FWIW, I think I will physically move the cvs directory to a > new location, wiping out all hints of cinstall from winsup. Yeah, I was going to suggest we do something like that. I've copied it over to /cvs/cygwin-apps/setup, chowned it to be owned by cygwin-apps, and test checking out the setup200202 branch - all of which worked fine. So... want me to remove the (now obsolete) cinstall directory, or would you like to do the honours? I'll work on getting setup to build outside the winsup tree this weekend. Rob
RE: cygwin ld import library issue fix (removing unused "_nm_" symbols)
Ralf Habacker > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Danny Smith > Sent: Thursday, April 25, 2002 10:12 PM > To: Ralf Habacker; Kde-Cygwin; Binutils; Cygwin-Apps > Subject: 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. > I have tried some analysis and got the following result: old = binutils 20011002 new = binutils 20020425 (cvs HEAD) funcs linking dll app old old - no problems old new - no problems new old - undefined reference error new new - undefined reference error auto-imported data linking dll app old old - no problems old new - BFD 2.12.90 20020425 internal error, aborting at section.c line 1073 in bfd_map_over_sections new old - undefined reference error new new - undefined reference error Any ideas ? Ralf
Question about DOS text file.
The GCC version 2.95.3-5 come with cygwin version 1.3.10 as a package cancompile C source file with DOS end-of-line character. However, the GCC built by myself can not compile DOS C file correctly.Here is the C source file:1 #define ABC 1,\2 2,\3 34 5 void main()6 {7 }If this C program is saved as a DOS text file, my GCC will complainabout line 2. If this C program is saved as a UNIX text file, compileis OK.It seems like my GCC compiler can not detect DOS end-of-line (CR/LF).Is there any flag to set while building the GCC or any GCC options canhandle the DOS text file format?ThanksBernardGet more from the Web. FREE MSN Explorer download : http://explorer.msn.com
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.57&con
tent-type=text/x-cvsweb-markup&cvsroot=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.
2001-12-17 Alan Modra <[EMAIL PROTECTED]>
* 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.
Then this file could only be affected
2001-12-16 Hans-Peter Nilsson <[EMAIL PROTECTED]>
* scripttempl/mmo.sc: Add .debug_ranges to listed sections.
>
> 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)
--- 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)
> 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
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)
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)
> 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: ITP: swig-1.3.11-1
Obviously, more than just the FTP server was messed up. While fixing a problem with their web-based HTML editing system, my ISP somehow managed to delete all of my files AND change my FTP password. >:o Perhaps it's a blessing in disguise. Since you hadn't gotten it yet, I took this opportunity to replace the setup.hint as I indicated earlier. Anyway, the files should all be there now... -Jerry -O Gerald S. Williams, 55A-134A-E : mailto:[EMAIL PROTECTED] O- -O AGERE SYSTEMS, 6755 SNOWDRIFT RD : office:610-712-8661 O- -O ALLENTOWN, PA, USA 18106-9353: mobile:908-672-7592 O- Corinna Vinschen wrote: > On Wed, Apr 24, 2002 at 02:09:19PM -0400, Gerald S. Williams wrote: > > The package files can be retrieved from: > > http://www.users.fast.net/~gwilliams/cygwin_swig/swig-1.3.11-1-src.tar.bz2 > > http://www.users.fast.net/~gwilliams/cygwin_swig/swig-1.3.11-1.tar.bz2 > > http://www.users.fast.net/~gwilliams/cygwin_swig/setup.hint > > $ wget 'http://www.users.fast.net/~gwilliams/cygwin_swig/swig-1.3.11-1.tar.bz2' > --13:15:02-- >http://www.users.fast.net/%7Egwilliams/cygwin_swig/swig-1.3.11-1.tar.bz2 >=> `swig-1.3.11-1.tar.bz2' > Connecting to www.users.fast.net:80... connected! > HTTP request sent, awaiting response... 404 File Not Found > 13:15:03 ERROR 404: File Not Found. > > That happens with all files.
RE: patch for "objdump/cygwin crashes on auto-imported libs" bug
Hi all,
I have applied the patch to the latest cvs release:
bfd/ChangeLog---
2002-04-25 Ralf Habacker <[EMAIL PROTECTED]>
* peXXigen.c (pe_print_idata): bugfix for segfault in
displaying auto-import image-import-descriptors
bfd/peXXigen.c---
$ cvs diff peXXigen.c
Index: peXXigen.c
===
RCS file: /cvs/src/src/bfd/peXXigen.c,v
retrieving revision 1.6
diff -u -3 -p -b -B -r1.6 peXXigen.c
--- peXXigen.c 30 Jan 2002 16:07:28 - 1.6
+++ peXXigen.c 25 Apr 2002 18:24:10 -
@@ -1224,7 +1224,15 @@ pe_print_idata (abfd, vfile)
idx2 = first_thunk - adj;
- for (j = 0; j < datasize; j += 4)
+ /* indicates that first_thunk points to an
+ data reference in the text segment (auto-import) */
+ if (idx2 < 0)
+{
+fprintf (file,
+ _("\tThe Import Address Table isn't identical (auto-import
descriptor)\n"));
+differ = 1;
+}
+ else for (j = 0; j < datasize; j += 4)
{
int ordinal;
char *member_name;
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: patch for "objdump/cygwin crashes on auto-imported libs" bug
> -Original Message-
> > From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, April 26, 2002 12:09 AM
> >
> > Any comments ?
>
> Looks reasonable to me (on first glances). I'll try and have a closer
> look this weekend if no-one else does.
Perhaps it helps, if I tell some details of this topic. At first the basics are
described in http://msdn.microsoft.com/msdnmag/issues/02/03/PE2/PE2.asp. See
the chapter "The import sections"
Normally the image_import_descriptor and the Image Adress Table (IAT) identifed
by "first_thunk" are located behind the text segment and idx2 is positive.
On a auto-import image descriptor the main difference is, that the first_thunk
does not point to the import address table (IAT), instead it points to an adress
in the text segment where the opcode reads or write the (auto-imported) data
values. This let idx2 be negative, which I have used for decision.
pe_print_idata (abfd, vfile)
adj = section->vma - extra->ImageBase;
0x0040
hint_addr = bfd_get_32 (abfd, data + i + dataoff);
time_stamp = bfd_get_32 (abfd, data + i + 4 + dataoff);
forward_chain = bfd_get_32 (abfd, data + i + 8 + dataoff);
dll_name = bfd_get_32 (abfd, data + i + 12 + dataoff);
first_thunk = bfd_get_32 (abfd, data + i + 16 + dataoff);
if (hint_addr != first_thunk && time_stamp == 0)
{
int differ = 0;
int idx2;
idx2 = first_thunk - adj;
/* indicates that first_thunk points to an
data reference in the text segment (auto-import) */
if (idx2 < 0)
{
fprintf (file,
_("\tThe Import Address Table isn't identical (auto-import
descriptor)\n"));
differ = 1;
}
else for (j = 0; j < datasize; j += 4)
Regards
Ralf
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)
> + // RH: prevent generating reimported functions Do not use C++ style comments in C code. It is non-portable.
Re: cinstall location
On Fri, Apr 26, 2002 at 01:32:08AM +1000, Robert Collins wrote: > sometime ago in a conversation about cinstall and the all-in-one >setup the topic of cinstall's location was rasied. At that point I >didn't see any need to move cinstall but I'd actually like to see it >moved to the cygwin-apps repository now. > >Why? >So that we can add a build dependency on a mingw libstdc++, and be done >with reinventing multiple wheels. > >I think that while moving won't be trauma-less, it will result in more >rapid development, and that can only be a good thing. It will also make >having a cinstall -src tarball easier, and the cygwin src snapshots >smaller. > >It's not intended to lessen the link between cinstall and cygwin at all, >rather to make building it easier. > >What do you think? I have no problems moving it. It never really fit into the winsup hierarchy. I put it there because I didn't want to make a new upper level directory on src and there was no cygwin-apps at the time. Let's rename the directory to 'setup', though. FWIW, I think I will physically move the cvs directory to a new location, wiping out all hints of cinstall from winsup. cgf
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
cinstall location
Chris, sometime ago in a conversation about cinstall and the all-in-one setup the topic of cinstall's location was rasied. At that point I didn't see any need to move cinstall but I'd actually like to see it moved to the cygwin-apps repository now. Why? So that we can add a build dependency on a mingw libstdc++, and be done with reinventing multiple wheels. I think that while moving won't be trauma-less, it will result in more rapid development, and that can only be a good thing. It will also make having a cinstall -src tarball easier, and the cygwin src snapshots smaller. It's not intended to lessen the link between cinstall and cygwin at all, rather to make building it easier. What do you think? Rob
RE: patch for "objdump/cygwin crashes on auto-imported libs" bug
> -Original Message- > From: Ralf Habacker [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 12:09 AM > > Any comments ? Looks reasonable to me (on first glances). I'll try and have a closer look this weekend if no-one else does. Rob
patch for "objdump/cygwin crashes on auto-imported libs" bug
Hi all,
currently I'm working on an ordinal linking option for ld (performance benefits
for the kde-port) and have analysed the auto-import internals. While doing this
I got the knowledge to fix the bug
described in http://sources.redhat.com/ml/binutils/2002-01/msg00093.html.
$ diff -ubBp bfd/peigen.c.org bfd/peigen.c
--- bfd/peigen.c.orgThu Apr 25 15:37:26 2002
+++ bfd/peigen.cThu Apr 25 15:57:50 2002
@@ -1226,7 +1226,15 @@ pe_print_idata (abfd, vfile)
idx2 = first_thunk - adj;
- for (j = 0; j < datasize; j += 4)
+ /* indicates that first_thunk points to an
+ data reference in the text segment (auto-import) */
+ if (idx2 < 0)
+{
+ fprintf (file,
+_("\tThe Import Address Table isn't identical (auto-import
descriptor)\n"));
+differ = 1;
+ }
+ else for (j = 0; j < datasize; j += 4)
{
int ordinal;
char *member_name;
bfd/ChangeLog---
2002-04-25 Ralf Habacker <[EMAIL PROTECTED]>
* peigen.c (pe_print_idata): bugfix for segfault in
displaying auto-import image-import-descriptors
Any comments ?
Ralf
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've taken a look on the cvs archive to verify this. Are I'm right using the cygnus_cvs_20020108_pre tag ? > Ralf
Re: ITP: swig-1.3.11-1
On Wed, Apr 24, 2002 at 02:09:19PM -0400, Gerald S. Williams wrote: > I have a Cygwin SWIG package ready for review and/or upload. > (Sorry, this is my first package. Is ITP the right keyword > to use?) > > The package files can be retrieved from: > > http://www.users.fast.net/~gwilliams/cygwin_swig/swig-1.3.11-1-src.tar.bz2 > http://www.users.fast.net/~gwilliams/cygwin_swig/swig-1.3.11-1.tar.bz2 > http://www.users.fast.net/~gwilliams/cygwin_swig/setup.hint $ wget 'http://www.users.fast.net/~gwilliams/cygwin_swig/swig-1.3.11-1.tar.bz2' --13:15:02-- http://www.users.fast.net/%7Egwilliams/cygwin_swig/swig-1.3.11-1.tar.bz2 => `swig-1.3.11-1.tar.bz2' Connecting to www.users.fast.net:80... connected! HTTP request sent, awaiting response... 404 File Not Found 13:15:03 ERROR 404: File Not Found. That happens with all files. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
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)
--- 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!
cygwin ld import library issue fix (removing unused "_nm_" symbols)
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
