Bug 745837 – dev-libs/tomsfastmath-0.13.1 fails to compile when changing CC

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Agostino Sarubbo 2020-10-01 06:49:43 UTC]

https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/

Issue: dev-libs/tomsfastmath-0.13.1 fails to compile.
Discovered on: amd64 (internal ref: tinderbox)

NOTE:
This machine uses a gold linker (ld.gold).
If you think that this issue is strictly related to ld.gold please block bug 269315.

[Comment 1 Agostino Sarubbo 2020-10-01 06:49:45 UTC]

Created attachment 663334 [details]
build.log

build log and emerge --info

[Comment 2 Agostino Sarubbo 2020-10-01 06:49:46 UTC]

Possible context of error(s):

/usr/bin/libtool: line 10610: x86_64-pc-linux-gnu-clang: command not found

[Comment 3 Michael Orlitzky 2020-10-01 11:28:09 UTC]

The first occurrence of "clang" in the build log is the line where it tries to link using "x86_64-pc-linux-gnu-clang". I don't think that's a lucky guess. What were CC, LD, etc. on the box during this build?

[Comment 4 Agostino Sarubbo 2020-10-01 11:31:50 UTC]

My guess it that this issue happens because libtool has been compiled with clang. But I have no idea on how to prevent this class of bugs..

[Comment 5 Sam James 2020-11-03 11:52:28 UTC]

(In reply to Agostino Sarubbo from comment #4)
> My guess it that this issue happens because libtool has been compiled with
> clang. But I have no idea on how to prevent this class of bugs..

CCing base-system, toolchain for advice here.

I don't think this is a core problem in tomsfastmath, but a general issue like you say with mixing libtool in some circumstances. 

If there *is* anything for us to do though, I'll of course do it - as soon as I figure out what :)

[Comment 6 Michael Orlitzky 2020-11-03 14:39:41 UTC]

I commented on the linked libtool bug with a way to fix this:

https://bugs.gentoo.org/88596#c43

[Comment 7 Michael Orlitzky 2021-04-03 16:37:45 UTC]

You may just want to close this as a duplicate of bug #88596. The best solution that has been proposed is to switch to slibtool (https://bugs.gentoo.org/show_bug.cgi?id=slibtool) for the global install. Regardless, there's nothing anyone can do within tomsfastmath short of autotoolizing the whole thing to address the issue.

[Comment 8 Sergei Trofimovich (RETIRED) 2021-04-29 07:29:24 UTC]

I think the primary bug here is the use of system libtool for linking. I'd say gentoo should nto provide it at all.

As libtool is embedding toolchain name and and version-specific object files right into the script it's not safe to use it against a different toolchain.

Autotools-based systems usually generate ./libtool at ./configure time. You can generate it with a few lines of configure.ac:

    $ cat configure.ac
    AC_PREREQ([2.59])

    AC_INIT
    AC_CONFIG_MACRO_DIRS([m4])
    LT_INIT()

    AC_OUTPUT

$ autoreconf --install
$ ./configure
$ file ./libtool
./libtool: POSIX shell script, ASCII text executable, with very long lines (916), with escape sequences

[Comment 9 Michael Orlitzky 2021-05-04 12:22:03 UTC]

(In reply to Sergei Trofimovich from comment #8)
> I think the primary bug here is the use of system libtool for linking. I'd
> say gentoo should nto provide it at all.
> 

I agree in principle, but we have a lot of packages that use the system "libtool" without autotools. Many of those upstream projects have made that decision intentionally and won't accept patches that add autotools. What do we do in those cases? Carrying custom patches that rewrite the build system is not a good option.

I don't know for certain if it would be possible to replace all "libtool" invocations with $(CC).

[Comment 10 Sergei Trofimovich (RETIRED) 2021-05-04 17:10:34 UTC]

(In reply to Michael Orlitzky from comment #9)
> (In reply to Sergei Trofimovich from comment #8)
> > I think the primary bug here is the use of system libtool for linking. I'd
> > say gentoo should nto provide it at all.
> > 
> 
> I agree in principle, but we have a lot of packages that use the system
> "libtool" without autotools. Many of those upstream projects have made that
> decision intentionally and won't accept patches that add autotools. What do
> we do in those cases? Carrying custom patches that rewrite the build system
> is not a good option.

I don't think it has to be a rewrite.

#comment8 is an example that does not require touching existing build system at all. It could (and probably should) be created in a standalone temp directory (say, in src_prepare()).

Sounds like a good use case for a tiny eclass. Is we add that temp directory to a $PATH I'd expect we could get away with zero changes to existing build system.

This package should be a reasonable example to try it on.

> I don't know for certain if it would be possible to replace all "libtool"
> invocations with $(CC).

I'd say it should not be necessary.