-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/08/2014 03:27 PM, Robin H. Johnson wrote:
> On Wed, Jan 08, 2014 at 09:14:43PM +0100, Peter Stuge wrote:
>> Robin H. Johnson wrote:
>>> Comments:
>>> -
>>> In bug #4411, comment 43, vapier noted:
any package that does dlopen("libfoo.
On Wed, Jan 08, 2014 at 09:14:43PM +0100, Peter Stuge wrote:
> Robin H. Johnson wrote:
> > Comments:
> > -
> > In bug #4411, comment 43, vapier noted:
> > > any package that does dlopen("libfoo.so") without the version info like
> > > ".so.X" is broken.
> > In this case, the lt_dlopenext c
Robin H. Johnson wrote:
> Comments:
> -
> In bug #4411, comment 43, vapier noted:
> > any package that does dlopen("libfoo.so") without the version info like
> > ".so.X" is broken.
> In this case, the lt_dlopenext consumer is explicitly testing multiple
> versions of libusb at runtime, and
On Mon, Jan 06, 2014 at 01:23:53PM -0600, William Hubbs wrote:
> The reason that gen_usr_ldscript exists is that we do not install
> static libraries in /. I think the argument for this is that they
> aren't needed at boot time. I would agree that they are not, but, given
> all of the issues we ha
The reason that gen_usr_ldscript exists is that we do not install
static libraries in /. I think the argument for this is that they
aren't needed at boot time. I would agree that they are not, but, given
all of the issues we have had in the past with gen_usr_ldscript, and
that issues keep coming u
Summary:
gen_ld_script is removing a vital unversioned symlink from some packages, and
this breaks libtool lt_dlopenext consumers at runtime.
Details:
While examining bug #486640, I discovered a concerning interaction [1] between
libtool's lt_dlopenext and gen_ld_script.
I don't
