Page MenuHome GnuPG

add support for illumos to our version of libtool
Closed, WontfixPublic

Description

This can create a libtool version conflict when the version of libtool used to generate the files in the repo differs from the version installed on the host. Needless to say, it breaks the build. This problem affects both libgpg-error and libgcrypt, maybe other gnupg projects too.

Event Timeline

werner added a subscriber: werner.

You may not run your own version of libtool or libtoolize. Only the maintainer updates the autotools related files including libtool. This is to avoid bugs stemming from different or broken versions of autotools. This makes it much easier to reproduce bugs.

If you think any file is not tracked in the repo, please let us know.

The version of libtool that you ship does not have the necessary patches required to support my platform. Normally this isn't a problem because autogen.sh (or autoreconf) will update it.

If you want to make the official policy "only the maintainer updates the autotools..." then that's fine, but for folks like me that have no choice life would be a bit easier if autogen.sh did what it supposed to.

justus triaged this task as Wishlist priority.Jun 12 2017, 11:41 AM
marcus claimed this task.
marcus added a subscriber: marcus.

No response.

The platform is illumos, a fork of OpenSolaris.

marcus removed projects: Info Needed, Not A Bug, libgcrypt.

libgpg-error is a placeholder project for the master version of our libtool, but all other packages are likely to be affected as well.

marcus renamed this task from autogen.sh forgets to run libtoolize to add support for illumos to our version of libtool.Aug 3 2017, 6:34 PM

Can you provide a patch for our version of the libtool macros that only adds support for illumos?

Forgive me. I was biting my tongue.

Serious though, for me and numerous other maintainers you'd be doing us a favour if you got whatever changes gpg-error depended on upstreamed and started depending on the new version once it's released.

We expect that the pre-patched version supplied by the system will be picked up and are a bit disappointed when it's not. Having to deal with projects that have decided to fork things like libtool is a headache.

For now I'll live with patching autogen.sh to include a call to libtoolize, which does the trick for me.

I know exactly what you mean, but werner disagrees so that's not going to happen.

I merely said, that we won't replace libtool by the upstream version because that lacks other important changes we need. Upstream was not willing to integrate our changes for Windows support and also introduced a lot of other regressions as well as dropping support for some platforms. Thus we need to maintain our version.

So what are the changes required for your platform and what is the cpu-vendor-os string (config.guess output)?

werner claimed this task.
werner added a project: Info Needed.

I close this bug as wontfix. If you can provide the requested changes for libtool please re-open this bug.