[patch #6691] FreeMiNT support to libtool 1.5.26 (tested)
URL: http://savannah.gnu.org/patch/?6691 Summary: FreeMiNT support to libtool 1.5.26 (tested) Project: GNU Libtool Submitted by: alanh Submitted on: Sun Dec 14 21:04:14 2008 Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any ___ Details: Attached is a patch to libtool 1.5.26 which supports the Atari FreeMiNT platform. ___ File Attachments: --- Date: Sun Dec 14 21:04:14 2008 Name: libtool-1.5.26-mint.patch Size: 884B By: alanh http://savannah.gnu.org/patch/download.php?file_id=17060 ___ Reply to this item at: http://savannah.gnu.org/patch/?6691 ___ Message sent via/by Savannah http://savannah.gnu.org/
[patch #6691] FreeMiNT support to libtool 1.5.26 (tested)
Follow-up Comment #1, patch #6691 (project libtool): Thanks for the patch. We'd much prefer it if you redid the patch against the current git tree (or 2.2.6 if you like), ran the testsuite (make -k check; see README for details and verbose output), and posted verbose output for all failed test groups. All of that we'd prefer to be posted to the libtool-patches mailing list. You don't have to be subscribed to the list to post (but there is first-post moderation). Please don't mix the djgpp and the mint case in the second hunk of your patch; that'll only confuse people into thinking mint and djgpp were somehow related. Also, I think you may need a few more changes to libtool.m4 and ltdl.m4. Thanks! Ralf ___ Reply to this item at: http://savannah.gnu.org/patch/?6691 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/
Re: Migrating from 1.5.x to 2.2.x
Dan Nicholson wrote: On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl jcurln...@arcor.de wrote: Ralf Wildenhues wrote: Hello Jason, * Jason Curl wrote on Thu, Dec 11, 2008 at 10:19:57PM CET: Ignoring that my macro obviously won't work with 2.2.x, I'm using Cygwin and I've come across my first problem. The old libtool is removed (1.5.27a) and the new is installed (at least I think the old is removed). I deleted my aclocal.m4 file and I autoreconf. I do see that the new libtool is being picked up by autotools as when configure I get errors where I'd expect and it knows not to check for C++ or Fortran anymore. config.lt generates the file libtool and thats where things start to get stuck. 'get stuck' is pretty vague. Please make it more specific by posting the command you issued, and cut-and-pasting its output. Since you seem to have a macro that interferes with Libtool macros, please post it, too (or a link if it's large or you've already posted it). Showing contents of configure.ac can help, too, but I'd be able to tell better with more information. OK - a libtoolize works around the problem. And ./libtool --version now shows 2.2.6. I would bet that you ran bare autoreconf. libtoolize is only run when you pass --install to autoreconf. As Ralf points out, passing --verbose to autoreconf can be very helpful while producing little extra output. You're right, I only ran autoreconf. libtoolize fixed the problem. A concern I have about libtoolize, it copies libtool.m4 and lt*.m4 files to my m4 macro directory. This is OK so long as all development platforms where I might run autoreconf are configured the same. I've tested to autoreconf my project on Ubuntu 8.10 that has by default libtool-2.2.4, where my Cygwin installation has libtool-2.2.6a. If I go backwards I get warnings. And I've already had a problem that during building the software the libtool scripts hung. All this occurs as soon as when the macros in m4/lt*.m4 don't match that which are installed on the local machine. I never had this issue with libtool-1.5.23 to libtool-1.5.26. Also what irks at the moment, is where does the libtool-1.5.x libtool that is generated by configure come from, if I don't have the m4/lt*.m4 macros in my project? Do I still have an installation problem? I was hoping these libtool macros don't need to be part of my project and would be pulled from the installation. That way it's always guaranteed to be using the right macros when I run autoreconf. In that regard, I miss having libtool-1.5. It was simpler. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Migrating from 1.5.x to 2.2.x
Jason Curl wrote: Dan Nicholson wrote: On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl jcurln...@arcor.de wrote: Ralf Wildenhues wrote: [SNIP] You're right, I only ran autoreconf. libtoolize fixed the problem. A concern I have about libtoolize, it copies libtool.m4 and lt*.m4 files to my m4 macro directory. This is OK so long as all development platforms where I might run autoreconf are configured the same. I've tested to autoreconf my project on Ubuntu 8.10 that has by default libtool-2.2.4, where my Cygwin installation has libtool-2.2.6a. If I go backwards I get warnings. And I've already had a problem that during building the software the libtool scripts hung. All this occurs as soon as when the macros in m4/lt*.m4 don't match that which are installed on the local machine. I never had this issue with libtool-1.5.23 to libtool-1.5.26. I always had this issue with version 2.x on all projects that include libtool macros in acinclude.m4. This is the case when user try to recreate autotools scripts. Work around is known - manually(!) remove (replace) libtool macros from acinclude.m4. As from 2.x libtool team recommend macros to be in separate files and now is more easy to refresh them. Also this isn't only libtool issue. In a project all macros from and external(dependent) has to be synchronized with you version of this package. If macros rare from new or old version is possible configure script to fail. This is integration problem(issue). Overwriting external m4 files in a project with those from system help in most cases, but not all. The hang of libtool may be is similar to KDevelop issue : http://lists.gnu.org/archive/html/bug-libtool/2008-05/msg00086.html [SNIP] Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Migrating from 1.5.x to 2.2.x
Roumen Petrov wrote: Jason Curl wrote: Dan Nicholson wrote: On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl jcurln...@arcor.de wrote: Ralf Wildenhues wrote: [SNIP] You're right, I only ran autoreconf. libtoolize fixed the problem. A concern I have about libtoolize, it copies libtool.m4 and lt*.m4 files to my m4 macro directory. This is OK so long as all development platforms where I might run autoreconf are configured the same. I've tested to autoreconf my project on Ubuntu 8.10 that has by default libtool-2.2.4, where my Cygwin installation has libtool-2.2.6a. If I go backwards I get warnings. And I've already had a problem that during building the software the libtool scripts hung. All this occurs as soon as when the macros in m4/lt*.m4 don't match that which are installed on the local machine. I never had this issue with libtool-1.5.23 to libtool-1.5.26. I always had this issue with version 2.x on all projects that include libtool macros in acinclude.m4. This is the case when user try to recreate autotools scripts. Work around is known - manually(!) remove (replace) libtool macros from acinclude.m4. As from 2.x libtool team recommend macros to be in separate files and now is more easy to refresh them. Also this isn't only libtool issue. In a project all macros from and external(dependent) has to be synchronized with you version of this package. If macros rare from new or old version is possible configure script to fail. This is integration problem(issue). Overwriting external m4 files in a project with those from system help in most cases, but not all. I guess this would only be a problem when using undocumented features of the autotools. I still don't know why autoreconf couldn't find the libtool.m4, lt*.m4 packages directly from it's own /usr/share/libtool (or similar) repository that is guaranteed to match the libtool that is installed, instead of having to have a symbolic link to that installation location in anycase. As I posted in an earlier post, if I don't have these m4 macros, configure generates a libtool in the current directory that says its version 1.5.26, so it appears I must do it the way libtoolize wants. The hang of libtool may be is similar to KDevelop issue : http://lists.gnu.org/archive/html/bug-libtool/2008-05/msg00086.html Similar, but between libtool-2.2.4 (Ubuntu 8.10) and libtool-2.2.6 (Cygwin 1.5.x) Thanks for your tips Roumen. ___ http://lists.gnu.org/mailman/listinfo/libtool
