GNOME Bugzilla – Bug 726518
g-ir-scanner: make --libtool= a no-op on OpenBSD
Last modified: 2015-02-07 17:01:38 UTC
Created attachment 272137 [details] [review] force libtool to /usr/bin/libtool on OpenBSD Hi. I would like to get some comments on the following patch. We've been using some variations of this in the last 3 years in OpenBSD ports tree. libtool(1) on OpenBSD is a completely different program and is part of the OS; GNU libtool does not properly work there (which is what softwares usually bundle in their release tarballs) -- so make it a no-op. Any opinion or better way to handle this? Thank you.
We have some of the same issues on FreeBSD mostly due to the fact that libtool on FreeBSD is a disaster. We solve this by passing a LIBTOOL= argument to make, which works fine for now. I think you should do that if you want to do this kind of overriding because otherwise you're going to have to petition a lot of people to make changes like this... Meanwhile, maybe you could contribute your OpenBSD-specific improvements to upstream libtool? This would benefit people who just casually download stuff and build it on OpenBSD (which would happen using the in-tree libtool, by default).
(In reply to comment #1) > We have some of the same issues on FreeBSD mostly due to the fact that libtool > on FreeBSD is a disaster. We solve this by passing a LIBTOOL= argument to > make, which works fine for now. Hi Ryan. Yes but this does not work. Passing LIBTOOL= works for autotools, not for things that use stuffs like: g-ir-scanner --libtool=../../libtool > I think you should do that if you want to do this kind of overriding because > otherwise you're going to have to petition a lot of people to make changes like > this... > > Meanwhile, maybe you could contribute your OpenBSD-specific improvements to > upstream libtool? This would benefit people who just casually download stuff > and build it on OpenBSD (which would happen using the in-tree libtool, by > default). We tried that a countless times, it ended up being a lost cause. Which is why we started our own libtool. Not to mention that patches that "may" end up in upstream libtool make take a while to be included in the libtool script some projects are bundling.
(In reply to comment #2) > Yes but this does not work. Passing LIBTOOL= works for autotools, not for > things that use stuffs like: > g-ir-scanner --libtool=../../libtool If projects are hardcoding this in their use of g-ir-scanner then that is their fault. The common use here is to use $(LIBTOOL) (and the real common use it to use the .m4 macros -- and they do that). I've been dealing with those cases by filing bugs against individual projects with patches to move them over to using the macros and everyone has been happy to accept those patches (after some light prodding). > We tried that a countless times, it ended up being a lost cause. Which is why > we started our own libtool. Not to mention that patches that "may" end up in > upstream libtool make take a while to be included in the libtool script some > projects are bundling. I feel your pain there, having tried to contribute to libtool in the past. For what it's worth, upstream libtool recently realised that they have had a rather high barrier to contribution and are trying to do something about it. http://lists.gnu.org/archive/html/libtool-patches/2013-12/msg00000.html It might be useful to try again?
> If projects are hardcoding this in their use of g-ir-scanner then that is their > fault. The common use here is to use $(LIBTOOL) (and the real common use it to > use the .m4 macros -- and they do that). > > I've been dealing with those cases by filing bugs against individual projects > with patches to move them over to using the macros and everyone has been happy > to accept those patches (after some light prodding). OK fair enough. I'll just keep it as a local patch in our ports tree. Thanks for the comment. > I feel your pain there, having tried to contribute to libtool in the past. For > what it's worth, upstream libtool recently realised that they have had a rather > high barrier to contribution and are trying to do something about it. > > http://lists.gnu.org/archive/html/libtool-patches/2013-12/msg00000.html > > It might be useful to try again? It is too late now, we have moved on with our own libtool(1).
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]