RE: libtool devel auto-import broken
I made some minor modifications because I am using a patched binutils (for preventing all symbols in the global scope from being exported) with which libtool cannot find a sed pattern for finding symbols to export when a .sym file is not given. The test for the "checking to see how to parse nm-B output" (or something like that) fails and an empty sed pattern is tried when searching for symbols causing the build to fail. Thanks for the URL, Stephano Mariani > -Original Message- > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > Sent: Sunday, 17 March 2002 5:6 PM > To: Stephano Mariani > Cc: 'Robert Collins'; 'CygWin-Apps' > Subject: Re: libtool devel auto-import broken > > Okay, the testing versions of automake-devel (automake-1.6) and > libtool-devel (libtool-20020316) are up at >http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/ > > If you use the latest setup.exe snapshot, add that URL to the 'download > locations' list, and use setup to install these test versions. > > --Chuck > > P.S. libtool-20020316 passes all of the tests (except quote which fails, > and build-relink/build-relink2 which are skipped). This is the same as > libtool-20020202. > > Stephano -- what minor modifications? My 20020316 version of libtool > includes Robert's original patch... > > Stephano Mariani wrote: > > > I see. In any case, your patch was just the ticket (with some minor > > modifications) :). I can now build my libraries as intended without all > > the symbols in the global scope being exported. :) > > > > Thanks, > > Stephano Mariani > > > > > > > >>-Original Message- > >>From: Robert Collins [mailto:[EMAIL PROTECTED]] > >>Sent: Sunday, 17 March 2002 12:2 PM > >>To: Stephano Mariani; Charles Wilson > >>Cc: CygWin-Apps > >>Subject: RE: libtool devel auto-import broken > >> > >> > >> > >> > >>>-Original Message- > >>>From: Stephano Mariani [mailto:[EMAIL PROTECTED]] > >>>Sent: Sunday, March 17, 2002 10:52 PM > >>>To: Robert Collins; 'Charles Wilson' > >>>Cc: 'CygWin-Apps' > >>>Subject: RE: libtool devel auto-import broken > >>> > >>> > >>>I understand that, but you mentioned that what is being > >>>accomplished by patching binutils is also possible by other > >>>means that do not involve rebuilding ld; libtool should be > >>>able to detect this and use the alternate method... I don't > >>>mind supplying a list of symbols to export. > >>> > >>>If this is not possible, then please excuse my ignorance as > >>>to the inner workings of libtool :) > >>> > >>Sorry, crossed wires. We needed *different* functionality to what you > >>are talking about, that was what we patched binutils for. > >> > >>Rob > >> > > > > >
RE: libtool devel auto-import broken
I see. In any case, your patch was just the ticket (with some minor modifications) :). I can now build my libraries as intended without all the symbols in the global scope being exported. :) Thanks, Stephano Mariani > -Original Message- > From: Robert Collins [mailto:[EMAIL PROTECTED]] > Sent: Sunday, 17 March 2002 12:2 PM > To: Stephano Mariani; Charles Wilson > Cc: CygWin-Apps > Subject: RE: libtool devel auto-import broken > > > > > -Original Message- > > From: Stephano Mariani [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, March 17, 2002 10:52 PM > > To: Robert Collins; 'Charles Wilson' > > Cc: 'CygWin-Apps' > > Subject: RE: libtool devel auto-import broken > > > > > > I understand that, but you mentioned that what is being > > accomplished by patching binutils is also possible by other > > means that do not involve rebuilding ld; libtool should be > > able to detect this and use the alternate method... I don't > > mind supplying a list of symbols to export. > > > > If this is not possible, then please excuse my ignorance as > > to the inner workings of libtool :) > > Sorry, crossed wires. We needed *different* functionality to what you > are talking about, that was what we patched binutils for. > > Rob
RE: libtool devel auto-import broken
I understand that, but you mentioned that what is being accomplished by patching binutils is also possible by other means that do not involve rebuilding ld; libtool should be able to detect this and use the alternate method... I don't mind supplying a list of symbols to export. If this is not possible, then please excuse my ignorance as to the inner workings of libtool :) Thanks, Stephano Mariani > -Original Message- > From: Robert Collins [mailto:[EMAIL PROTECTED]] > Sent: Sunday, 17 March 2002 11:24 AM > To: Stephano Mariani; Charles Wilson > Cc: CygWin-Apps > Subject: RE: libtool devel auto-import broken > > > > > -Original Message- > > From: Stephano Mariani [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, March 17, 2002 9:44 PM > > To: Robert Collins; 'Charles Wilson' > > Cc: 'CygWin-Apps' > > Subject: RE: libtool devel auto-import broken > > > > > > Isn't it better to have this functionality within libtool... > > doesn't it exist for this purpose? Personally, I would love a > > tool that allows me to build shared libs on windows/cygwin, > > linux, and solaris with ease. > > libtool can't add functionality not supported by the native tools, it > can only encapsulate and script such functionality. > > Search the cygwin and gcc and libtool lists for "auto-import Paul" or > "auto-import Robert" or "auto-import Charles" for more historical info. > > Rob
RE: libtool devel auto-import broken
Isn't it better to have this functionality within libtool... doesn't it exist for this purpose? Personally, I would love a tool that allows me to build shared libs on windows/cygwin, linux, and solaris with ease. Stephano Mariani > -Original Message- > From: Robert Collins [mailto:[EMAIL PROTECTED]] > Sent: Sunday, 17 March 2002 10:19 AM > To: Stephano Mariani; Charles Wilson > Cc: CygWin-Apps > Subject: RE: libtool devel auto-import broken > > > > > -----Original Message- > > From: Stephano Mariani [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, March 17, 2002 9:12 PM > > To: 'Charles Wilson'; Robert Collins > > Cc: 'CygWin-Apps' > > Subject: RE: libtool devel auto-import broken > > > > > > I would like to test these new versions of the autotools if I > > may. I am a very autotools dependent user and use it > > frequently enough to warrant dissecting it and learning much > > more about their internals :) > > > > I have noticed however that using automake (1.5) and libtool > > (1.4e) there is no way to prevent symbols being exported. I > > have therefore had to resort to patching my binutils to > > prevent every symbol from being exported :( > > There is a bin-utils export-filter command you can use instead of > patching IIRC. Mind you, we resorted to patching binutils to get libtool > to do what we want :]. > > Rob
RE: libtool devel auto-import broken
I would like to test these new versions of the autotools if I may. I am a very autotools dependent user and use it frequently enough to warrant dissecting it and learning much more about their internals :) I have noticed however that using automake (1.5) and libtool (1.4e) there is no way to prevent symbols being exported. I have therefore had to resort to patching my binutils to prevent every symbol from being exported :( Thanks for the great tools, Stephano Mariani > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > On Behalf Of Charles Wilson > Sent: Sunday, 17 March 2002 9:25 AM > To: Robert Collins > Cc: CygWin-Apps > Subject: Re: libtool devel auto-import broken > > Hmmm...there's a line in ltmain.sh that says: > > -allow-undefined) > # FIXME: remove this flag sometime in the future. > $echo "$modename: \`-allow-undefined' is deprecated because it > is the default" 1>&2 > continue > ;; > > Actually, libtool.m4 is an original file. It isn't generated from > anything AFAIK. Anyway, I updated to the most recent libtool CVS, and > whaddaya know -- almost all of your patches have made it in. The > attached patch is all that's left "outside" (and it also includes the > patch you just posted). > > I'll whip up a new libtool-devel package soon. What's the story with > the automake-1.6 package I put up? Had a chance to play with it yet? > > --Chuck > > Robert Collins wrote: > > > the following patch (to the created file I know, sorry short of time) > > corrects a recent regression, related to libtol tags I think, that > > prevents libtool using auto-import in some cases. > > > > Cheers, > > Rob
RE: RFP: UPX (Was Re: reducing binary distribution size with UPX)
I never intended to imply that the packages should be distributed compressed, but perhaps UPX functionality could (in the distant not so near future) be integrated into setup, such that the installed files could be compressed at the users discretion based on its size. :) Stephano Mariani > -Original Message- > From: Robert Collins [mailto:[EMAIL PROTECTED]] > Sent: Saturday, 16 March 2002 11:7 PM > To: Stephano Mariani; Gerrit P. Haase; Lapo Luchini > Cc: [EMAIL PROTECTED] > Subject: RE: RFP: UPX (Was Re: reducing binary distribution size with UPX) > > > > > -Original Message- > > From: Stephano Mariani [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, March 17, 2002 6:30 AM > > To: 'Gerrit P. Haase'; 'Lapo Luchini' > > Cc: [EMAIL PROTECTED] > > Subject: RE: RFP: UPX (Was Re: reducing binary distribution > > size with UPX) > > > > > > Hi! > > > > I have used UPX a lot recently, and have found it very > > useful; however, I would not recommend compressing all > > binaries with it. Instead, to get a good compromise between > > size and speed, why not just compress those files that are > > the least used, and/or largest. > > Compressing any distributed files will be up to the individual > maintainer. It's not something that a hard-and-fast call can be made on. > I think that having it in the distro, for folk to use/test at their own > discretion is useful though. > > Rob
RE: RFP: UPX (Was Re: reducing binary distribution size with UPX)
Hi! I have used UPX a lot recently, and have found it very useful; however, I would not recommend compressing all binaries with it. Instead, to get a good compromise between size and speed, why not just compress those files that are the least used, and/or largest. For example, on my system, the largest files are (not including dlls since someone posted that they do not compress well): gs.exe* gdb.exe* lynx.exe* cvs.exe* postgres.exe* openssl.exe* vim.exe* dvipdfm.exe* squid.exe* links.exe* pdfetex.exe* mutt.exe* pdftex.exe* ld.exe* objdump.exe* as.exe* objcopy.exe* strip.exe* bash.exe* expect.exe* omfonts.exe* gprof.exe* irc-20010101.exe* Of these, I would not compress ld, as, and possibly cvs since I don't want to incur a performance hit, but the rest will considerably reduce the size with a minimal loss of speed :). Stephano Mariani PS: The UPX stubs are *very* fast anyway :) > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > On Behalf Of Gerrit P. Haase > Sent: Saturday, 16 March 2002 2:38 PM > To: Lapo Luchini > Cc: [EMAIL PROTECTED] > Subject: Re: RFP: UPX (Was Re: reducing binary distribution size with UPX) > > Hallo Lapo, > > Am 2002-03-16 um 12:16 schriebst du: > > >> We should not precompress delivered binaries (besides setup.exe > maybe?). > >> It will not reduce the size of the packages very much. > > > We could maybe include in the UPX file also two shell scripts: compress > everything > > and decompress everything, just to ease things to users. > > It is pretty easy to type in: `upx /bin/*.exe`;) > > Give it a try, pack it up and offer it for inclusion (UCL too). > > > Gerrit > -- > =^..^= > >
Cproto package
Hi, I was wondering what the procedure was to get a package submitted to cygwin, I have read the docs on the website, and would like to volunteer my services as a package maintainer for cproto (http://cproto.sf.net). TIA, Stephano Mariani
