| Summary: | Should libtool package install ltmain.sh into staging ? | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Nick Leverton <nick> |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | buildroot, nick |
| Priority: | P5 | ||
| Version: | 2010.02 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: | Patch to copy ltmain.sh to the staging area. | ||
So you're suggesting to replace package/buildroot-libtool.patch by a copy of a "sane" ltmain.sh ? 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). 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). |
Created attachment 1669 [details] 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 ?