Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Message-ID: <020601c0f27b$d579ea90$0200a8c0@lifelesswks> From: "Robert Collins" To: Cc: , , "Paul Sokolovsky" Subject: ld --auto-import for cygwin and libtool Date: Mon, 11 Jun 2001 23:38:42 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 11 Jun 2001 13:28:36.0030 (UTC) FILETIME=[6AEE2DE0:01C0F27A] I've cc'd this for wide exposure. I'm looking for any tests that folk would like to see on Paul Sokolvsky's auto-import PE hack in order to consider it for inclusion in binutils. Libtool could benefit from this patch, as it would allow fully automatic dll building on cygwin, _but_ the patch should be widely available for that to be worth considering. Paul a while back made a rather neat hack to pe to allow automatic importing of symbols without needing decoration. This allows libraries to be built with out any decoration in the headers - ie in standard UNIX format. AFAIK the patch has languished due to no one reviewing it. So... I've spent some time putting it through it's paces, and it seems to work without any issues at all. There were some teething issue, due to the patch not being developed for Cygwin, but for pw32. Thats been resolved (see below). I'm very happy with the way the patch performs, it builds all the existing decorated code I could find without trouble, and quite happily builds fully non-decorated code. Ralf Habacker has built KDE 1 with it, with a modified libtool. I've uploaded to my homepage a modified libtool 1.4 that uses gcc -shared and Paul's auto-import ld. This libtool passes all tests including tests that fail with the current production cygwin code except 1) build-relink.test spits out "shlibpath_overrides_runpath should be set to yes." I'm not sure what that should be for cygwin, so I'm referring the question to the libtool list :]. I'm happy to dig further if the issue is a bug, but if setting this to yes is the correct action there's little to do :]. 2) quote.test - which I have discussed in the copied email below. My homepage can currently be found at http://users.bigpond.net.au/robertc I've also uploaded a binutils src tarball with the modified ld. I've modified it a little further to avoid some cygwin dll symbols it was picking up by mistake. A patch for that against a recent binutils is there as well. My patch also differs from Paul's original in that I've left disabled the auto-image-base option, which can cause issues with cygwin, due to a issue previously discussed. That option isn't part of the auto-import logic and thus shouldn't be part of this discussion IMO. (And should not be enabled by default!). I may well have broken libtool stuff, and there are things that can be tidied a bit, but this should work for anyone with the modified ld. Also the ld indenting is probably naffed, but it should be good enough for review by anyone interested. I'm not subscribed to binutils, but am to libtool - if you just reply to binutils I'll miss your reply. Rob ----- Original Message ----- From: "Robert Collins" To: "Gary V.Vaughan" Sent: Monday, June 11, 2001 9:19 PM Subject: libtool that passes all tests > I'm down to depdemo-nofast with no failures. I think that by the time I > go to bed tonight I'll likely have a nearly-no-failures cygwin libtool > here. Are you interested in a tarball of such a thing (with a copy of > Paul's ld ?) > > (the failures are: quote.test is failing, "error on mkdir .libs" but I > think thats because cygwin returns an error when you mkdir an existing > directory - does unix return an error for that? build-relink.test is > also failing, and thats my current target. ) > > I ask whether you want that in preference to a patch, because with the > MLB merge, I imagine that any patch will be outdated before I can blink. > Also I don't know if I've broken any other things or not :]. > > I have one change that definately isn't a proper solution - and thats > the extra_LIBS thing I asked about on the list a few days ago. The .dll > needs to go in the search path, or the test script needs to add the > libs/extra dir to the normal path when the test is run on cygwin, for a > proper solution. > > Of course, the ld needs proper peer review, but I figured that a fully > functional libtool would be a good starting point for saying "well it > seems to work" :] > > Rob >