| 1 |
On Sat, 18 Mar 2017 19:29:36 +0000 |
| 2 |
Peter Stuge <peter@×××××.se> wrote: |
| 3 |
|
| 4 |
> Alexis Ballier wrote: |
| 5 |
> > > If elibtoolize results in different binaries being produced, then |
| 6 |
> > > it's done wrong in the first place. AFAIU the primary goal of |
| 7 |
> > > elibtoolize logic is to fix issues on recent systems with |
| 8 |
> > > outdated build systems. Which is certainly not something that |
| 9 |
> > > needs to be done for every user out there. |
| 10 |
> > |
| 11 |
> > You probably didn't have a look at what the patches fix. Having a |
| 12 |
> > quick look at patches there, |
| 13 |
> |
| 14 |
> Where are those patches you mention? |
| 15 |
|
| 16 |
Those in ELT-patches... |
| 17 |
|
| 18 |
> > I could fine one fixing relink to old libs (from / instead of $D), |
| 19 |
> |
| 20 |
> I have an open bug for this for a package, both in Gentoo and |
| 21 |
> upstream. It seems to be a problem with libtool itself, is that |
| 22 |
> about right? |
| 23 |
|
| 24 |
With recent libtools it is most likely to be the package's fault, like |
| 25 |
wrong/poor usage of autotools. |
| 26 |
|
| 27 |
|
| 28 |
> > another one fixing parallel install. The former produces broken |
| 29 |
> > binaries, the latter none at all. |
| 30 |
> > |
| 31 |
> > I seriously doubt this shouldn't be fixed for every user. |
| 32 |
> |
| 33 |
> What "this" do you refer to? Sorry for the confusion, I want to |
| 34 |
> understand. |
| 35 |
|
| 36 |
|
| 37 |
the bugs |
Archives