From: ericonr <ericonr@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [PR PATCH] [Merged]: libtool: revbump for the gcc update.
Date: Wed, 10 Feb 2021 01:48:30 +0100 [thread overview]
Message-ID: <20210210004830.s0Vz9huPi6yRVkvk3sfHgd8_adjY5s54SrhgzXQSSLY@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-28577@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 2076 bytes --]
There's a merged pull request on the void-packages repository
libtool: revbump for the gcc update.
https://github.com/void-linux/void-packages/pull/28577
Description:
libtool hardcodes some internal gcc paths, which include the GCC version
information. Some applications can fail to build if these paths are
used. Revbumping libtool is enough for the recorded paths to be updated.
A proper solution is importing the fixes Debian applies:
https://salsa.debian.org/metux-guest/libtool/-/blob/ef64614b54a8da38fc4b4424639251fde9d135bf/debian/rules#L115
This is ugly as hell, but I don't want to do the work to import the debian workaround properly right now. But maybe I should :P
Noticed when building https://sourceforge.net/projects/srecord/files/srecord/1.64/ , reported via IRC.
<!-- Mark items with [x] where applicable -->
#### General
- [ ] This is a new package and it conforms to the [quality requirements](https://github.com/void-linux/void-packages/blob/master/Manual.md#quality-requirements)
#### Have the results of the proposed changes been tested?
- [x] I use the packages affected by the proposed changes on a regular basis and confirm this PR works for me
- [ ] I generally don't use the affected packages but briefly tested this PR
<!--
If GitHub CI cannot be used to validate the build result (for example, if the
build is likely to take several hours), make sure to
[skip CI](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#continuous-integration).
When skipping CI, uncomment and fill out the following section.
Note: for builds that are likely to complete in less than 2 hours, it is not
acceptable to skip CI.
-->
<!--
#### Does it build and run successfully?
(Please choose at least one native build and, if supported, at least one cross build. More are better.)
- [ ] I built this PR locally for my native architecture, (ARCH-LIBC)
- [ ] I built this PR locally for these architectures (if supported. mark crossbuilds):
- [ ] aarch64-musl
- [ ] armv7l
- [ ] armv6l-musl
-->
prev parent reply other threads:[~2021-02-10 0:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-08 3:14 [PR PATCH] " ericonr
2021-02-08 3:15 ` ericonr
2021-02-10 0:45 ` ericonr
2021-02-10 0:48 ` [PR PATCH] [Updated] " ericonr
2021-02-10 0:48 ` ericonr [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210210004830.s0Vz9huPi6yRVkvk3sfHgd8_adjY5s54SrhgzXQSSLY@z \
--to=ericonr@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).