Bug 926232

Summary:	dev-libs/bglibs-2.04-r1 - hardcodes GNU libtool in a ltcompile script
Product:	Gentoo Linux	Reporter:	orbea <orbea>
Component:	Current packages	Assignee:	No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed>
Status:	CONFIRMED ---
Severity:	normal	CC:	mjo, orbea
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Bug Depends on:
Bug Blocks:	765709

Description orbea 2024-03-06 04:35:13 UTC

In an environment with slibtool enabled it forces GNU libtool by hardcoding it in a generated ltcompile script.

Reproducible: Always

Comment 1 Michael Orlitzky gentoo-dev

2025-02-08 02:22:29 UTC

How badly do you want this?

Not only is "libtool" echoed into ltcompile, it's also hard-coded in one (*.c) source file. This isn't an autotools project, so rlibtool doesn't work. And while most libraries are shared, there's ONE lib that needs to be static. So if you are guessing what to put in LIBTOOL, it's a headache.

The ebuild depends on GNU libtool, so while it will use the "wrong" tool, it should still build and function on a system where slibtool is used globally.

Comment 2 orbea 2025-02-08 02:32:02 UTC

I don't use this package and only reported it because its a problem concerning slibtool. This was when I was actively working on slibtool integration in Gentoo which unfortunately has been stalled for reasons entirely out of my hands...