Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
libuv, llvm, clang build fails [SOLVED thanks Hu!]
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
jesnow
l33t
l33t


Joined: 26 Apr 2006
Posts: 653

PostPosted: Sat Jul 04, 2020 1:44 pm    Post subject: libuv, llvm, clang build fails [SOLVED thanks Hu!] Reply with quote

Stable nodejs will not emerge unless I keyword libuv-1.38.0-r1,
so I keyworded it and it won't compile at all. [edit previous version 1.37 dies with the same error.]:

Code:

checking if x86_64-pc-linux-gnu-gcc supports -Wno-long-long flag... yes
checking if x86_64-pc-linux-gnu-gcc supports -Wno-unused-parameter flag... yes
checking if x86_64-pc-linux-gnu-gcc supports -Wstrict-prototypes flag... yes
checking for x86_64-pc-linux-gnu-ar... x86_64-pc-linux-gnu-ar
checking the archiver (x86_64-pc-linux-gnu-ar) interface... unknown
configure: error: could not determine x86_64-pc-linux-gnu-ar interface

!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/dev-libs/libuv-1.38.0-r1/work/libuv-1.38.0-abi_x86_64.amd64/config.log
 * ERROR: dev-libs/libuv-1.38.0-r1::gentoo failed (configure phase):
 *   econf failed



Sure enough in config.log:
Code:

configure:4480: checking for x86_64-pc-linux-gnu-ar
configure:4496: found /usr/bin/x86_64-pc-linux-gnu-ar
configure:4507: result: x86_64-pc-linux-gnu-ar
configure:4577: checking the archiver (x86_64-pc-linux-gnu-ar) interface
configure:4593: x86_64-pc-linux-gnu-gcc -c -O2 -pipe -std=gnu89 -Wall -Wextra -Wno-long-long -Wno-unused-parameter -Wstrict
-prototypes  conftest.c >&5
configure:4593: $? = 0
configure:4595: x86_64-pc-linux-gnu-ar cru libconftest.a conftest.o >&5
Two passes with the same argument (-amdgpu-argument-reg-usage-info) attempted to be registered!
/var/tmp/portage/dev-libs/libuv-1.38.0-r1/work/libuv-1.38.0/configure: line 4596:   605 Segmentation fault      $AR cru lib
conftest.a conftest.$ac_objext 1>&5
configure:4598: $? = 139
configure:4604: x86_64-pc-linux-gnu-ar -NOLOGO -OUT:conftest.lib conftest.o >&5
x86_64-pc-linux-gnu-ar: invalid option -- 'L'
Usage: x86_64-pc-linux-gnu-ar [emulation options] [-]{dmpqrstx}[abcDfilMNoOPsSTuvV] [--plugin <name>] [member-name] [count]
 archive-file file...
       x86_64-pc-linux-gnu-ar -M [<mri-script]
 commands:
  d            - delete file(s) from the archive
  m[ab]        - move file(s) in the archive
  p            - print file(s) found in the archive
  q[f]         - quick append file(s) to the archive
  r[ab][f][u]  - replace existing or insert new file(s) into the archive
  s            - act as ranlib
  t[O][v]      - display contents of the archive
  x[o]         - extract file(s) from the archive
 command specific modifiers:
  [a]          - put file(s) after [member-name]
  [b]          - put file(s) before [member-name] (same as [i])



All help gratefully accepted.


jesnow


Last edited by jesnow on Sun Jul 05, 2020 4:28 pm; edited 1 time in total
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15824

PostPosted: Sat Jul 04, 2020 4:47 pm    Post subject: Re: libuv emerge fails Reply with quote

jesnow wrote:
Code:
configure:4595: x86_64-pc-linux-gnu-ar cru libconftest.a conftest.o >&5
Two passes with the same argument (-amdgpu-argument-reg-usage-info) attempted to be registered!
/var/tmp/portage/dev-libs/libuv-1.38.0-r1/work/libuv-1.38.0/configure: line 4596:   605 Segmentation fault      $AR cru lib conftest.a conftest.$ac_objext 1>&5
configure:4598: $? = 139
configure:4604: x86_64-pc-linux-gnu-ar -NOLOGO -OUT:conftest.lib conftest.o >&5
It looks like there are two problems here. The first, and more serious, is that your assembler crashes when given a seemingly routine request. The second, minor, problem is that the configure test misinterprets that crash as an indication that it should then try using Microsoft assembler options. This is silly and useless, and produces a misleading error. It should stop on the basis that the assembler crashed.

The questions then become:
  • Is that diagnostic about -amdgpu relevant? I don't know why it would even appear here, so its presence suggests something odd is happening.
  • Why is your assembler crashing?
Can you build other programs? Are you using an assembler wrapper, as some people do for LTO support?
Back to top
View user's profile Send private message
jesnow
l33t
l33t


Joined: 26 Apr 2006
Posts: 653

PostPosted: Sat Jul 04, 2020 6:15 pm    Post subject: Reply with quote

Dear Hu:

You are indeed onto the problem, which is much more complicated than I thought. In fact I have several packages that are failing on upgrade today, and the errors are seemingly related but still mysterious. I don't know why the assembler is crashing, but amdgpu indeed seems to be involved, as does lto (why? it's not activated, but there's no documentation) and llvm/clang upgrade to 10.0.0.


Code:

bartali /home/jesnow/garb # emerge -DNup world

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ~] dev-libs/libuv-1.38.0-r1 [1.37.0]
[ebuild     U #] net-libs/nodejs-14.5.0 [14.4.0]
[ebuild     U  ] sys-devel/lld-10.0.0 [9.0.1]
[ebuild  NS    ] sys-devel/clang-10.0.0 [9.0.1] LLVM_TARGETS="-ARC% -AVR%"
[ebuild  NS    ] sys-libs/compiler-rt-10.0.0 [9.0.1]
[ebuild  NS    ] sys-libs/compiler-rt-sanitizers-10.0.0 [9.0.1]
[ebuild  NS    ] sys-devel/clang-runtime-10.0.0 [9.0.1]
[ebuild  rR   ~] media-libs/mesa-20.1.1
[ebuild     U  ] x11-libs/gtk+-3.24.20 [3.24.16]
[ebuild  NS    ] app-emulation/wine-vanilla-5.0.1 [5.0]
[ebuild     U  ] media-gfx/inkscape-1.0-r1 [0.92.4-r3] USE="-graphicsmagick% (-jemalloc) -svg2%" PYTHON_SINGLE_TARGET="python3_7%* (-python3_8)"
bartali /home/jesnow/garb #



But they have this in common:

Code:

bartali /home/jesnow/garb # grep amdgpu *.log
clang.build.log:Two passes with the same argument (-amdgpu-argument-reg-usage-info) attempted to be registered!
gtk+.build.log:Two passes with the same argument (-amdgpu-argument-reg-usage-info) attempted to be registered!
inkscape.build.log:Two passes with the same argument (-amdgpu-argument-reg-usage-info) attempted to be registered!
wine.build.log:Two passes with the same argument (-amdgpu-argument-reg-usage-info) attempted to be registered!
wine.build.log:Two passes with the same argument (-amdgpu-argument-reg-usage-info) attempted to be registered!


At least libuv has the decency to barf at config time!

I don't know how this problem is related to ar, which my understanding has something to do with archives (!) is it in fact part of the assembler?

Code:

bartali /home/jesnow/garb # which ar
/usr/bin/ar
bartali /home/jesnow/garb # readlink -f `which ar`
/usr/x86_64-pc-linux-gnu/binutils-bin/2.33.1/ar


This is to my mind how it should be, so I don't know why ar is failing. The google says that people who are migrating to system clang with lto are having issues like this, but since the gentoo documentation I can find on lto is scarce I don't know how to troubleshoot it. This is an inherited setup from Cloveros, and it's taking me months to find all the things he riced and turn them off. You may question my wisdom for having gone this route on my new fast machine, but it's what I've done.

Any insights what to look for?

[update:]

llvm was compiled with the aggressive compiler flags from cloveros, it exhimited the same behavior and bombed when I turned them off:

Code:

bartali /home/jesnow/garb # cat /etc/portage/env/no-nosinter
CFLAGS="-Ofast -march=x86-64 -mtune=generic -mfpmath=both -pipe -flto=8 -fdevirtualize-at-ltrans -fgraphite-identity -floop-nest-optimize -funroll-loops -fipa-pta -ftracer -fno-plt -malign-data=cacheline -mtls-dialect=gnu2 -Wl,--hash-style=gnu"
CXXFLAGS="${CFLAGS}"


I don't know what half these compiler flags do, so I would rather turn them off. But if instead you turn them *on* for clang, it compiles.

[update 2]

After a day of monkeying with these stupid compiler flags I am done. I deleted most of /etc/portage/package.env (which had hundreds of lines setting custom compiler flags for every package) and am doing emerge -e world.


Nope that didn't work either, as now bzip2 and ncurses refuse to compile igving the same maddening error:

Code:


>>> Source configured.
>>> Compiling source in /var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6 ...
 * abi_x86_32.x86: running multilib-minimal_abi_src_compile
make -j50 -l12 VPATH=/var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6 'CC=x86_64-pc-linux-gnu-gcc -m32' AR=x86_64-pc-linux-gnu-ar RANLIB=x86_64-pc-linux-gnu-ranlib -f /var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6/Makefile-libbz2_so all
x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -fpic -fPIC -Wall -Winline -D_FILE_OFFSET_BITS=64  -c /var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6/blocksort.c
x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -fpic -fPIC -Wall -Winline -D_FILE_OFFSET_BITS=64  -c /var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6/huffman.c
x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -fpic -fPIC -Wall -Winline -D_FILE_OFFSET_BITS=64  -c /var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6/crctable.c
x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -fpic -fPIC -Wall -Winline -D_FILE_OFFSET_BITS=64  -c /var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6/randtable.c
x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -fpic -fPIC -Wall -Winline -D_FILE_OFFSET_BITS=64  -c /var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6/compress.c
x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -fpic -fPIC -Wall -Winline -D_FILE_OFFSET_BITS=64  -c /var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6/decompress.c
x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -fpic -fPIC -Wall -Winline -D_FILE_OFFSET_BITS=64  -c /var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6/bzlib.c
x86_64-pc-linux-gnu-gcc -m32 -Wl,-O1 -Wl,--as-needed -shared -Wl,-soname -Wl,libbz2.so.1 -o libbz2.so.1.0.6 blocksort.o huffman.o crctable.o randtable.o compress.o decompress.o bzlib.o
ln -sf libbz2.so.1.0.6 libbz2.so.1.0
make -j50 -l12 VPATH=/var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6 'CC=x86_64-pc-linux-gnu-gcc -m32' AR=x86_64-pc-linux-gnu-ar RANLIB=x86_64-pc-linux-gnu-ranlib -f /var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6/Makefile all 'LDFLAGS=-Wl,-O1 -Wl,--as-needed '
rm -f libbz2.a
x86_64-pc-linux-gnu-ar cq libbz2.a blocksort.o huffman.o crctable.o randtable.o compress.o decompress.o bzlib.o
x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -Wall -Winline -D_FILE_OFFSET_BITS=64  -c /var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6/bzip2.c
x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -Wall -Winline -D_FILE_OFFSET_BITS=64  -c /var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6/bzip2recover.c
Two passes with the same argument (-amdgpu-argument-reg-usage-info) attempted to be registered!
make: *** [/var/tmp/portage/app-arch/bzip2-1.0.6-r11/work/bzip2-1.0.6/Makefile:47: libbz2.a] Segmentation fault
make: *** Deleting file 'libbz2.a'
make: *** Waiting for unfinished jobs....




This post is a clue:
https://forums.gentoo.org/viewtopic-t-1109360-start-0.html

But I don't have LTO enabled as far as I know.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15824

PostPosted: Sat Jul 04, 2020 10:35 pm    Post subject: Reply with quote

I misread. The assembler is as. The archiver is ar.

Yes, attempting to recover an over-optimized system is probably what got you into this.

Please post the output of emerge --info ; cat /etc/portage/make.conf.
Back to top
View user's profile Send private message
jesnow
l33t
l33t


Joined: 26 Apr 2006
Posts: 653

PostPosted: Sat Jul 04, 2020 11:33 pm    Post subject: Reply with quote

It was a real mistake to base my install on cloveros. But at some level there are a lot of useful and interesting things in there I would like to learn from. But what I really wanted was a binhost to install a vanilla system to work forward from, not a super-tuned (I just checked myself on the adjective I used previously, that won't ever happen again) system to work backward.

make.conf
Your paste can be seen here: http://dpaste.com/2PK3KWY

emerge --info
Your paste can be seen here: http://dpaste.com/2MM5XAJ

The way he apparently works his magic is to put almost nothing in make.conf (most what's there I've added) but to force things in other places that are hard to find. Where are LLVM_TARGETS set? Why are all my emerges barfing over an option that's only relevant to compiling on an AMD GPU?

Many thanks!

Jon.
Back to top
View user's profile Send private message
Etal
Veteran
Veteran


Joined: 15 Jul 2005
Posts: 1739

PostPosted: Sat Jul 04, 2020 11:59 pm    Post subject: Reply with quote

This seems like the issue you're having: https://forums.gentoo.org/viewtopic-t-1109360-start-0.html
Back to top
View user's profile Send private message
jesnow
l33t
l33t


Joined: 26 Apr 2006
Posts: 653

PostPosted: Sun Jul 05, 2020 12:34 am    Post subject: Reply with quote

Etal wrote:
This seems like the issue you're having: https://forums.gentoo.org/viewtopic-t-1109360-start-0.html


Exactly, as I noted farther up this thread. But the thread offers a workaround only, not a solution. And the workaround didn't work.


This is interesting:

Code:

bartali /home/jesnow/garb # dir /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins
total 8
drwxr-xr-x 2 root root 4096 Jul  4 03:37 .
drwxr-xr-x 3 root root 4096 Mar 11 18:22 ..
lrwxrwxrwx 1 root root   59 Jul  4 02:59 liblto_plugin.so -> /usr/libexec/gcc/x86_64-pc-linux-gnu/9.3.0/liblto_plugin.so
lrwxrwxrwx 1 root root   41 Jul  4 03:37 LLVMgold.so -> ../../../../lib/llvm/10/lib64/LLVMgold.so


It looks like llvm 10 loads a plugin to ld.bfd that uses gold. Is that not a party foul, to trash the competing package?

Again for future generations: A mis-configured LLVM installation can break gcc using plugins.


Last edited by jesnow on Sun Jul 05, 2020 4:16 pm; edited 1 time in total
Back to top
View user's profile Send private message
jesnow
l33t
l33t


Joined: 26 Apr 2006
Posts: 653

PostPosted: Sun Jul 05, 2020 5:44 am    Post subject: Reply with quote

Almost solved I think. Caused by the transition to 10.0.0 of llvm/clang/etc.

get -fipa-pta and -fno-plt out of the cflags

# emerge -C llvm:9 llvm:10
# emerge llvm
# emerge @preserved-rebuild
# emerge -DNu @world

Still compiling, but nothing has bombed yet.

[update:]
Code:

# emerge -C llvm clang compiler-rt-sanitizers clang-runtime
# emerge -1 llvm clang compiler-rt-sanitizers clang-runtime


v4l-utils (video for linux) was the only thing requiring that LLVM/Clang be compiled for bpf, so just deactivate the use flag.
It's for the the infrared controller via LIRC. If you need that someday then put it back.

Not clear to me why this was so hard. Somebody should have figured this out before it went stable...
But if you use highly tuned compiler flags you are really on your own with this stuff.


Jon.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15824

PostPosted: Sun Jul 05, 2020 4:40 pm    Post subject: Reply with quote

Exotic flags historically were such a problem that I think a lot of people have decided just to permanently abandon using them, so they don't get thoroughly tested anymore. If the commonly chosen / "obvious" flags work, then it's considered good enough until someone raises a report to the contrary. People don't go looking for trouble, because of the odds that you can find it and sink a lot of time into figuring out which component is guilty.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum