New: Should libtool package install ltmain.sh into staging ?

https://bugs.busybox.net/show_bug.cgi?id=1711

Summary: Should libtool package install ltmain.sh into staging
?
Product: buildroot
Version: 2010.02
Platform: Other
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P5
Component: Other
AssignedTo: unassigned at buildroot.uclibc.org
ReportedBy: nick at leverton.org
CC: buildroot at uclibc.org
Estimated Hours: 0.0

Created attachment 1669
--> https://bugs.busybox.net/attachment.cgi?id=1669
Patch to copy ltmain.sh to the staging area.

I'm no libtool expert and I'm struggling to adapt a couple of packages which use it to Buildroot. Instead trying to find the incompatibilities and then to generate patches which mung the package's existing ltmain.sh, and which may well break when the package is updated, I'd like to be able to copy in the latest ltmain.sh, as is already done by gnuconfig for config.{guess,sub}.

At present I am doing this when required with a PACKAGE_POST_PATCH_HOOKS target. So there is no need to add extra Buildroot config items, potentially breaking other packages, as long as ltmain.sh is available in a known place.

If there's some reason why this is silly or otherwise not the best way to work, I'd welcome any advice. Otherwise please would you consider the attached patch to add ltmain.sh to the libtool staging files ?

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=1711

--- Comment #1 from Thomas Petazzoni <[email protected]> --- So you're suggesting to replace package/buildroot-libtool.patch by a copy of a "sane" ltmain.sh ?

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=1711

Nick Leverton <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |nick at leverton.org

--- Comment #2 from Nick Leverton <[email protected]> --- Heavens no, I'm not sure why it looks like I said that. Sorry. So many packages in buildroot rely on that file. Did my patch have a bad side effect on it ?

I'm wondering if there is any reason why the latest ltmain.sh shouldn't be available in the toolchain staging as-is, rather than going to the trouble of patching $RANDOM_LTMAIN from the upstream ? On my Debian packaging I find it's often (not always, admittedly) more trouble than it's worth to patch auto*/lt* rather than just use the distro's current version (BR's current build version chosen by the configurer, in this case).

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=1711

Thomas Petazzoni <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #3 from Thomas Petazzoni <[email protected]> --- I'm by far no libtool expert either, but the solution we have currently in Buildroot, which consists in patching ltmain.sh seems to work quite well for all the packages we have. That solution has been around for quite some time and has been very stable. The number of libtool versions to handle is relatively limited (three at the moment) and the different patches are very similar, so the maintainance burden is really not a problem.

Therefore, I'd prefer to keep the libtool patching mechanism as it is today, unless there are compelling reasons to change it (like a package not working in the current mechanism).

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.