Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 855602 - dev-lang/julia-1.7.3 fails to compile (lto): julia_internal.h:159:26: error: type of jl_cumulative_compile_time does not match original declaration [-Werror=lto-type-mismatch]
Summary: dev-lang/julia-1.7.3 fails to compile (lto): julia_internal.h:159:26: error: ...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Science Related Packages
URL:
Whiteboard:
Keywords:
: 866593 (view as bug list)
Depends on:
Blocks: lto
  Show dependency tree
 
Reported: 2022-07-01 20:15 UTC by Agostino Sarubbo
Modified: 2024-08-26 13:13 UTC (History)
4 users (show)

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


Attachments
build.log (build.log,576.11 KB, text/plain)
2022-07-01 20:15 UTC, Agostino Sarubbo
Details
build.log (build.log,63.01 KB, text/x-log)
2024-08-26 13:12 UTC, Eli Schwartz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2022-07-01 20:15:27 UTC
https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/

Issue: dev-lang/julia-1.7.3 fails to compile (lto).
Discovered on: amd64 (internal ref: lto_tinderbox)

NOTE:
This machine uses lto with CFLAGS=-flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
Comment 1 Agostino Sarubbo gentoo-dev 2022-07-01 20:15:30 UTC
Created attachment 789386 [details]
build.log

build log and emerge --info
Comment 2 Agostino Sarubbo gentoo-dev 2022-07-01 20:15:32 UTC
Error(s) that match a know pattern in addition to what has been reported in the summary:


rm: cannot remove '/var/tmp/portage/dev-lang/julia-1.7.3/work/julia-1.7.3/usr/manifest/SuiteSparse': No such file or directory
/var/tmp/portage/dev-lang/julia-1.7.3/work/julia-1.7.3/src/julia_internal.h:159:26: error: type of 'jl_cumulative_compile_time' does not match original declaration [-Werror=lto-type-mismatch[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wlto-type-mismatch]]
Comment 3 Agostino Sarubbo gentoo-dev 2022-07-26 09:00:49 UTC
Here is a bit of explanation:

-Werror=lto-type-mismatch:
User to find possible runtime issues in packages. It likely means the package is unsafe to build & use with LTO.
For projects using the same identifier but with different types across different files, they must be fixed to be consistent across the codebase.

-Werror=odr:
Used to find possible runtime issues in packages. These bugs are a problem anyway but may be even worse when combined with LTO. C++ code must comply with the One Definition Rule (ODR) - see https://en.cppreference.com/w/cpp/language/definition#One_Definition_Rule.

-Werror=strict-aliasing:
Used to find possible runtime issues in packages. These bugs are a problem anyway but may be even worse when combined with LTO.

Workarounds:
- If upstream is friendly and still active, file a bug upstream. For emulators, codecs, games, or multimedia packages, it may be worth just applying a workaround instead, as upstreams sometimes aren't receptive to these bugs (VALID FOR ALL).
- Use the new 'filter-lto' from flag-o-matic.eclass as it's likely to be unsafe with LTO (VALID FOR lto-type-mismatch - odr).
- Fix it yourself if interested, of course (VALID FOR ALL).
- Append-flags -fno-strict-aliasing (VALID FOR strict-aliasing).
- Use memcpy() but a union is sometimes suitable too (VALID FOR strict-aliasing).
- -fstrict-aliasing is implied by -O2, so this must be addressed in some form (VALID FOR strict-aliasing).

See also: https://marc.info/?l=gentoo-dev&m=165639574126280&w=2
Comment 4 Larry the Git Cow gentoo-dev 2022-07-26 21:40:49 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5fa56a38ce0a5ae9d983c795fe98cf2245726de1

commit 5fa56a38ce0a5ae9d983c795fe98cf2245726de1
Author:     Maciej Barć <xgqt@gentoo.org>
AuthorDate: 2022-07-26 21:39:19 +0000
Commit:     Maciej Barć <xgqt@gentoo.org>
CommitDate: 2022-07-26 21:40:47 +0000

    dev-lang/julia: filter LTO (type mismatch)
    
    Closes: https://bugs.gentoo.org/855602
    Signed-off-by: Maciej Barć <xgqt@gentoo.org>

 dev-lang/julia/julia-1.7.1-r4.ebuild | 5 ++++-
 dev-lang/julia/julia-1.7.3.ebuild    | 5 ++++-
 2 files changed, 8 insertions(+), 2 deletions(-)
Comment 5 Eli Schwartz gentoo-dev 2024-08-26 05:49:16 UTC
*** Bug 866593 has been marked as a duplicate of this bug. ***
Comment 6 Eli Schwartz gentoo-dev 2024-08-26 05:50:24 UTC
This was never fixed. The above commit was nonfunctional and I guess untested. It filtered LTO *after* the LTO flags were sed'ed into a Makefile.
Comment 7 Eli Schwartz gentoo-dev 2024-08-26 13:12:04 UTC
Created attachment 901268 [details]
build.log

With julia 1.9.4 it fails quite fast.

x86_64-pc-linux-gnu-gcc -o build/libblastrampoline.so.5 -g -O2 -std=c99 -fPIC -DLIBRARY_EXPORTS -D_GNU_SOURCE -pipe -march=native -fstack-protector-all -O2 -fdiagnostics-color=always -frecord-gcc-switches -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wformat -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -Werror=int-conversion -Werror=incompatible-pointer-types -DF2C_AUTODETECTION -DCBLAS_DIVERGENCE_AUTODETECTION -DCOMPLEX_RETSTYLE_AUTODETECTION -Wl,-soname=libblastrampoline.so.5 build/libblastrampoline.o build/dl_utils.o build/config.o build/autodetection.o build/threading.o build/deepbindless.o build/trampolines/trampolines_x86_64.o build/f2c_adapters.o build/cblas_adapters.o build/complex_return_style_adapters.o -shared -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wl,--defsym=__gentoo_check_ldflags__=0 -ldl -Wl,-z,noexecstack
libblastrampoline_complex_retdata.h:32:1: error: function 'cmplxret_zdotc_' redeclared as variable
   32 | COMPLEX128_FUNCS(XX)
      | ^
complex_return_style_adapters.c:18:16: note: previously declared here
   18 | double complex cmplxret_zdotc_(const int32_t * N,
      |                ^
libblastrampoline_complex_retdata.h:32:1: error: function 'cmplxret_zdotu_' redeclared as variable
   32 | COMPLEX128_FUNCS(XX)
      | ^
complex_return_style_adapters.c:46:16: note: previously declared here
   46 | double complex cmplxret_zdotu_(const int32_t * N,
      |                ^
libblastrampoline_complex_retdata.h:31:1: error: function 'cmplxret_cdotc_' redeclared as variable
   31 | COMPLEX64_FUNCS(XX)
      | ^
complex_return_style_adapters.c:74:15: note: previously declared here
   74 | float complex cmplxret_cdotc_(const int32_t * N,
      |               ^

[...]
lto1: fatal error: errors during merging of translation units
compilation terminated.
lto-wrapper: fatal error: x86_64-pc-linux-gnu-gcc returned 1 exit status
compilation terminated.
/usr/libexec/gcc/x86_64-pc-linux-gnu/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:64: build/libblastrampoline.so.5] Error 1

There's quite a lot of that repeated. bugzilla sensibly forbids uploading it all in one comment.
Comment 8 Larry the Git Cow gentoo-dev 2024-08-26 13:13:24 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1ca47163c2c7c223d2a120092c2489d007e4eeb7

commit 1ca47163c2c7c223d2a120092c2489d007e4eeb7
Author:     Eli Schwartz <eschwartz@gentoo.org>
AuthorDate: 2024-08-26 06:02:46 +0000
Commit:     Eli Schwartz <eschwartz@gentoo.org>
CommitDate: 2024-08-26 13:12:43 +0000

    dev-lang/julia: mark as LTO-unsafe
    
    julia has many problems, at many levels. Among these, it fails to build
    with LTO due to various errors somewhat more inventive than the norm
    when it comes to LTO issues. Iteration time on building and testing it
    is, of course, horrifically bad as it bundles its own private LLVM.
    
    I won't even try to run the testsuite. I tried that years ago on Arch.
    "Flaky" doesn't even begin to describe it -- an actual passing test
    result sometimes took me 7 builds in a row, and one is never sure why it
    actually passed for once. "Fortunately", the ebuild restricts tests
    anyway. Needless to say, who knows if it actually works.
    
    It seems to build. Probably. At least better than when -flto is used, so
    that's a win. On which note, it is worth pointing out: the ebuild
    *tried* to filter lto, but didn't do so early enough. This change simply
    lifts the filter early enough that it runs before a sed inserts CFLAGS
    into a Makefile, so that the filter actually takes effect.
    
    Bug NOT reported upstream. Julia is a language of all time, and
    reporting bugs gets you nowhere except the receiving end of a thorough
    gaslighting. I do not volunteer for this. The software is most likely
    broken (LTO warnings don't indicate a flawless codebase) but I simply
    don't care -- it's not my problem if this programming language is
    broken, as long as it isn't an obstacle to other, more useful packages,
    being safe to build by default with LTO enabled in make.conf.
    
    Closes: https://bugs.gentoo.org/855602
    Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>

 dev-lang/julia/julia-1.8.3-r4.ebuild | 7 ++++---
 dev-lang/julia/julia-1.8.5-r1.ebuild | 7 ++++---
 dev-lang/julia/julia-1.9.0.ebuild    | 7 ++++---
 dev-lang/julia/julia-1.9.4.ebuild    | 7 ++++---
 4 files changed, 16 insertions(+), 12 deletions(-)