Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 745837 - dev-libs/tomsfastmath-0.13.1 fails to compile when changing CC
Summary: dev-libs/tomsfastmath-0.13.1 fails to compile when changing CC
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Sam James
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-01 06:49 UTC by Agostino Sarubbo
Modified: 2021-05-04 17:10 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,82.35 KB, text/plain)
2020-10-01 06:49 UTC, Agostino Sarubbo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 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 gentoo-dev 2020-10-01 06:49:45 UTC
Created attachment 663334 [details]
build.log

build log and emerge --info
Comment 2 Agostino Sarubbo gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 archtester gentoo-dev Security 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 gentoo-dev 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 gentoo-dev 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) gentoo-dev 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 gentoo-dev 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) gentoo-dev 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.