Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
System breakage after gcc upgrade: 10.1.0-r2 -> 10.2.0
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM
View previous topic :: View next topic  
Author Message
Deathcrow
n00b
n00b


Joined: 24 Jul 2006
Posts: 32

PostPosted: Fri Jul 24, 2020 8:07 am    Post subject: System breakage after gcc upgrade: 10.1.0-r2 -> 10.2.0 Reply with quote

Hi there,

this occured on my ARM board:

Code:

... snip....
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include/g++-v10/ext/pb_ds/detail/bin_search_tree_
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include/g++-v10/ext/pb_ds/detail
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include/g++-v10/ext/pb_ds   
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include/g++-v10/ext                                     
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include/g++-v10/experimental/bits                       
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include/g++-v10/experimental                           
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include/g++-v10/decimal
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include/g++-v10/debug                                   
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include/g++-v10/bits                                   
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include/g++-v10/backward                                                                                                                                                       
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include/g++-v10/aarch64-unknown-linux-gnu/ext
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include/g++-v10/aarch64-unknown-linux-gnu/bits
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include/g++-v10/aarch64-unknown-linux-gnu
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include/g++-v10     
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include-fixed       
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/include                   
<<<          dir /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/finclude           
<<<          dir /usr/aarch64-unknown-linux-gnu/gcc-bin/10.1.0                               
[sys-devel/gcc-10.1.0-r2] bash: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory                                                                                                 
 * The ebuild phase 'postrm' has exited unexpectedly. This type of behavior                   
 * is known to be triggered by things such as failed variable assignments                 
 * (bug #190128) or bad substitution errors (bug #200313). Normally, before               
 * exiting, bash should have displayed an error message above. If bash did     
 * not produce an error message above, it's possible that the ebuild has                                               
 * called `exit` when it should have called `die` instead. This behavior                                               
 * may also be triggered by a corrupt bash binary or a hardware problem                   
 * such as memory or cpu malfunction. If the problem is not reproducible or   
 * it appears to occur randomly, then it is likely to be triggered by a                                                                                                                                                                       
 * hardware problem. If you suspect a hardware problem then you should try     
 * some basic hardware diagnostics such as memtest. Please do not report                                               
 * this as a bug unless it is consistently reproducible and you are sure                                               
 * that your bash binary and hardware are functioning properly.                                                       
[sys-devel/gcc-10.1.0-r2] sandbox: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory                                                                                               
 * The ebuild phase 'die_hooks' has exited unexpectedly. This type of                                                 
 * behavior is known to be triggered by things such as failed variable                                                 
 * assignments (bug #190128) or bad substitution errors (bug #200313).                                                 
 * Normally, before exiting, bash should have displayed an error message                                               
 * above. If bash did not produce an error message above, it's possible                                               
 * that the ebuild has called `exit` when it should have called `die`                                                 
 * instead. This behavior may also be triggered by a corrupt bash binary or                   
 * a hardware problem such as memory or cpu malfunction. If the problem is       
 * not reproducible or it appears to occur randomly, then it is likely to                                                                                                                                                                     
 * be triggered by a hardware problem. If you suspect a hardware problem                                                                                                                                                                       
 * then you should try some basic hardware diagnostics such as memtest.                   
 * Please do not report this as a bug unless it is consistently                   
 * reproducible and you are sure that your bash binary and hardware are                   
 * functioning properly.                                         
!!! FAILED postrm: 1                                                                                                   
 * The 'postrm' phase of the 'sys-devel/gcc-10.1.0-r2' package has failed                                         
 * with exit value 1.                                                                                                 
 *                                                                                                                     
 * The problem occurred while executing the ebuild file named                                             
 * 'gcc-10.1.0-r2.ebuild' located in the '/var/db/pkg/sys-                                                             
 * devel/gcc-10.1.0-r2' directory. If necessary, manually remove the                                         
 * environment.bz2 file and/or the ebuild file located in that directory.                                       
 *                                                                                                                     
 * Removal of the environment.bz2 file is preferred since it may allow the                                             
 * removal phases to execute successfully. The ebuild will be sourced and                                             
 * the eclasses from the current ebuild repository will be used when                                       
 * necessary. Removal of the ebuild file will cause the pkg_prerm() and                                               
 * pkg_postrm() removal phases to be skipped entirely.                                                                 
>>> Regenerating /etc/ld.so.cache...                                                                                                                                                                                                  [70/3748]
sh: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory                                                                                                                             
>>> Original instance of package unmerged safely.                                                                                                                                                                                             
[sys-devel/gcc-10.2.0] bash: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory                                                                                                     
 * The ebuild phase 'postinst' has exited unexpectedly. This type of                                                 
 * behavior is known to be triggered by things such as failed variable                                                                                                                                                                         
 * assignments (bug #190128) or bad substitution errors (bug #200313).                                                                                                                                                                         
 * Normally, before exiting, bash should have displayed an error message                                                                                                                                                                       
 * above. If bash did not produce an error message above, it's possible                                                                                                                                                                       
 * that the ebuild has called `exit` when it should have called `die`                                           
 * instead. This behavior may also be triggered by a corrupt bash binary or                   
 * a hardware problem such as memory or cpu malfunction. If the problem is                 
 * not reproducible or it appears to occur randomly, then it is likely to                                             
 * be triggered by a hardware problem. If you suspect a hardware problem                                               
 * then you should try some basic hardware diagnostics such as memtest.                                               
 * Please do not report this as a bug unless it is consistently                       
 * reproducible and you are sure that your bash binary and hardware are                                               
 * functioning properly.                                                                                               
[sys-devel/gcc-10.2.0] sandbox: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory                                                                                                 
 * The ebuild phase 'die_hooks' has exited unexpectedly. This type of                                       
 * behavior is known to be triggered by things such as failed variable                                       
 * assignments (bug #190128) or bad substitution errors (bug #200313).                                 
 * Normally, before exiting, bash should have displayed an error message           
 * above. If bash did not produce an error message above, it's possible           
 * that the ebuild has called `exit` when it should have called `die`                   
 * instead. This behavior may also be triggered by a corrupt bash binary or       
 * a hardware problem such as memory or cpu malfunction. If the problem is                   
 * not reproducible or it appears to occur randomly, then it is likely to                                                                                                                                                                     
 * be triggered by a hardware problem. If you suspect a hardware problem                     
 * then you should try some basic hardware diagnostics such as memtest.                   
 * Please do not report this as a bug unless it is consistently                           
 * reproducible and you are sure that your bash binary and hardware are       
 * functioning properly.                                                                                               
 * FAILED postinst: 1                                                                                                 
<<< !needed  sym /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/libgo.so.16                 
<<< !needed  obj /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0/libgo.so.16.0.0
[sys-devel/gcc-10.2.0] sandbox: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory                                                                                                 
 * The ebuild phase 'other' has exited unexpectedly. This type of behavior     
 * is known to be triggered by things such as failed variable assignments                                             
 * (bug #190128) or bad substitution errors (bug #200313). Normally, before                                           
 * exiting, bash should have displayed an error message above. If bash did                                             
 * not produce an error message above, it's possible that the ebuild has                                                                                                                                                                       
 * called `exit` when it should have called `die` instead. This behavior                                               
 * may also be triggered by a corrupt bash binary or a hardware problem                                               
 * such as memory or cpu malfunction. If the problem is not reproducible or                                           
 * it appears to occur randomly, then it is likely to be triggered by a                                               
 * hardware problem. If you suspect a hardware problem then you should try                                             
 * some basic hardware diagnostics such as memtest. Please do not report                                               
 * this as a bug unless it is consistently reproducible and you are sure                       
 * that your bash binary and hardware are functioning properly.                 
[sys-devel/gcc-10.2.0] bash: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory                                                                                                     
[sys-devel/gcc-10.2.0] sandbox: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory                                                                                                 
 * The ebuild phase 'die_hooks' has exited unexpectedly. This type of                     
 * behavior is known to be triggered by things such as failed variable           
 * assignments (bug #190128) or bad substitution errors (bug #200313).                     
 * Normally, before exiting, bash should have displayed an error message                                               
 * above. If bash did not produce an error message above, it's possible                                               
 * that the ebuild has called `exit` when it should have called `die`                                             
 * instead. This behavior may also be triggered by a corrupt bash binary or                                           
 * a hardware problem such as memory or cpu malfunction. If the problem is                                             
 * not reproducible or it appears to occur randomly, then it is likely to                                 
 * be triggered by a hardware problem. If you suspect a hardware problem                                               
 * then you should try some basic hardware diagnostics such as memtest.                                     
 * Please do not report this as a bug unless it is consistently                                                 
 * reproducible and you are sure that your bash binary and hardware are                                               
 * functioning properly.                                                                                               
                                                                                                                       
>>> Failed to execute postinst for sys-devel/gcc-10.2.0, Log file:                                         
                                                                                                                       
>>>  '/var/tmp/portage/sys-devel/gcc-10.2.0/temp/build.log'                                                           
                                                                                                                                                                                                                                               
 * Messages for package sys-devel/gcc-10.1.0-r2:                                                                                                                                                                                             
                                                                                                                                                                                                                                               
 * The ebuild phase 'postrm' has exited unexpectedly. This type of behavior                                                                                                                                                                   
 * is known to be triggered by things such as failed variable assignments                                           
 * (bug #190128) or bad substitution errors (bug #200313). Normally, before                                                                                                                                                                   
 * exiting, bash should have displayed an error message above. If bash did                                                                                                                                                                     
 * not produce an error message above, it's possible that the ebuild has                                                                                                                                                                       
 * called `exit` when it should have called `die` instead. This behavior                                                                                                                                                                       
 * may also be triggered by a corrupt bash binary or a hardware problem                                         
 * such as memory or cpu malfunction. If the problem is not reproducible or                   
 * it appears to occur randomly, then it is likely to be triggered by a                     
 * hardware problem. If you suspect a hardware problem then you should try                                             
 * some basic hardware diagnostics such as memtest. Please do not report                                               
 * this as a bug unless it is consistently reproducible and you are sure                                               
 * that your bash binary and hardware are functioning properly.                       
 * The 'postrm' phase of the 'sys-devel/gcc-10.1.0-r2' package has failed                                             
 * with exit value 1.                                                                                                 
 *                                                                                                                                                                                                                                             
 * The problem occurred while executing the ebuild file named                                               
 * 'gcc-10.1.0-r2.ebuild' located in the '/var/db/pkg/sys-                                                             
 * devel/gcc-10.1.0-r2' directory. If necessary, manually remove the                                   
 * environment.bz2 file and/or the ebuild file located in that directory.         
 *                                                                                                                     
 * Removal of the environment.bz2 file is preferred since it may allow the               
 * removal phases to execute successfully. The ebuild will be sourced and         
 * the eclasses from the current ebuild repository will be used when                         
 * necessary. Removal of the ebuild file will cause the pkg_prerm() and                                                                                                                                                                       
 * pkg_postrm() removal phases to be skipped entirely.                                                                 
                                                                                                                       
 * Messages for package sys-devel/gcc-10.2.0:                                                                         
                                                                                                                       
 * The ebuild phase 'postinst' has exited unexpectedly. This type of                                                   
 * behavior is known to be triggered by things such as failed variable                                                 
 * assignments (bug #190128) or bad substitution errors (bug #200313).                     
 * Normally, before exiting, bash should have displayed an error message       
 * above. If bash did not produce an error message above, it's possible                                                                                                                                                                       
 * that the ebuild has called `exit` when it should have called `die`         
 * instead. This behavior may also be triggered by a corrupt bash binary or                                           
 * a hardware problem such as memory or cpu malfunction. If the problem is                                             
 * not reproducible or it appears to occur randomly, then it is likely to                                             
 * be triggered by a hardware problem. If you suspect a hardware problem                                                                                                                                                                       
 * then you should try some basic hardware diagnostics such as memtest.                                               
 * Please do not report this as a bug unless it is consistently                                                       
 * reproducible and you are sure that your bash binary and hardware are                                               
 * functioning properly.                                                                                               
 * FAILED postinst: 1                                                                                                 
 * The ebuild phase 'other' has exited unexpectedly. This type of behavior                                             
 * is known to be triggered by things such as failed variable assignments                     
 * (bug #190128) or bad substitution errors (bug #200313). Normally, before     
 * exiting, bash should have displayed an error message above. If bash did                                                                                                                                                                     
 * not produce an error message above, it's possible that the ebuild has                                                                                                                                                                       
 * called `exit` when it should have called `die` instead. This behavior                   
 * may also be triggered by a corrupt bash binary or a hardware problem           
 * such as memory or cpu malfunction. If the problem is not reproducible or               
 * it appears to occur randomly, then it is likely to be triggered by a                                               
 * hardware problem. If you suspect a hardware problem then you should try                                             
 * some basic hardware diagnostics such as memtest. Please do not report                                         
 * this as a bug unless it is consistently reproducible and you are sure                                               
 * that your bash binary and hardware are functioning properly.                                                       
                                                                                                                       
 * GNU info directory index is up-to-date.                                                                             


This broke almost everything (no more ssh, su, etc). I was able to restore normal functionality by restoring /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0 from a backup, running a gcc-config towards the new 10.2.0 profile and then removing the /usr/lib/gcc/aarch64-unknown-linux-gnu/10.1.0 folder again.
Back to top
View user's profile Send private message
Ionen
Veteran
Veteran


Joined: 06 Dec 2018
Posts: 1111

PostPosted: Fri Jul 24, 2020 3:01 pm    Post subject: Reply with quote

Not something I'm overly familiar with but bash/sandbox/etc... using libgomp would imply it was build with -fopenmp I believe (or maybe other flags could use it too, not sure -- normally shouldn't be used unless it's some arm-specific requirement I'm not aware of), have you been using any odd CFLAGS?
Back to top
View user's profile Send private message
Deathcrow
n00b
n00b


Joined: 24 Jul 2006
Posts: 32

PostPosted: Fri Jul 24, 2020 3:09 pm    Post subject: Reply with quote

Ionen wrote:
Not something I'm overly familiar with but bash/sandbox/etc... using libgomp would imply it was build with -fopenmp I believe (or maybe other flags could affect this too, not sure -- normally they shouldn't be using it unless it's some arm-specific thing I'm not aware of), have you been using any odd CFLAGS?


Oh hey, thanks, that's a great observation. In my hectic I didn't even realize that this was caused by bash itself.

ldd /bin/bash
Code:

        linux-vdso.so.1 (0x0000ffff82252000)
        libreadline.so.8 => /lib64/libreadline.so.8 (0x0000ffff820be000)
        libtinfo.so.6 => /lib64/libtinfo.so.6 (0x0000ffff8206c000)
        libc.so.6 => /lib64/libc.so.6 (0x0000ffff81f03000)
        /lib/ld-linux-aarch64.so.1 => /lib64/ld-linux-aarch64.so.1 (0x0000ffff82222000)
        libtinfow.so.6 => /lib64/libtinfow.so.6 (0x0000ffff81eb1000)
        libgomp.so.1 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgomp.so.1 (0x0000ffff81e64000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000ffff81e50000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000ffff81e20000)


Code:

=================================================================
                        Package Settings
=================================================================

app-shells/bash-5.0_p18::gentoo was built with the following:
USE="net nls (readline) (-afs) -bashlogger -examples -mem-scramble -plugins"
CFLAGS="-O2 -pipe -fomit-frame-pointer -march=native -mtune=native"
CXXFLAGS="-O2 -pipe -fomit-frame-pointer -march=native -mtune=native"
LDFLAGS="-fuse-ld=bfd -Wl,--hash-style=gnu,-O2,--as-needed"


I **have** been messing around with fopenmp and clang about a year ago, or longer (there's still an old /etc/portage/env/ file for it). But I'm not sure where/how the library is still being pulled in. I'll have to investigate.

So this seems like it's almost certainly my fault somehow. (Thanks to btrfs and its snapshots for giving me a quick way out of my own foolishness).

I'll try just rebuilding bash and see where that leads me. If worse comes to worse i'll just settle for emerge -e @world.

Weird.


Last edited by Deathcrow on Fri Jul 24, 2020 3:13 pm; edited 1 time in total
Back to top
View user's profile Send private message
Ionen
Veteran
Veteran


Joined: 06 Dec 2018
Posts: 1111

PostPosted: Fri Jul 24, 2020 3:13 pm    Post subject: Reply with quote

libgomp is installed by gcc with USE=openmp but not directly in standard directories (it'll be around /usr/lib/gcc/*/*/libgomp.so.1 as seen in that ldd output), my guess is that it's not expected it to be needed so soon (aka, by bash and other basics), and it messed up rebuilding the library cache. That directory is defined by /etc/ld.so.conf.d/05gcc-*

Edit: it may be coming from one of bash's dependency too, like ncurses that you may not have rebuild in a while. If there's inconsistency in how things were built, then emerge -e @world doesn't sound like a bad idea
Back to top
View user's profile Send private message
Deathcrow
n00b
n00b


Joined: 24 Jul 2006
Posts: 32

PostPosted: Fri Jul 24, 2020 4:03 pm    Post subject: Reply with quote

Ionen wrote:

Edit: it may be coming from one of bash's dependency too, like ncurses that you may not have rebuild in a while. If there's inconsistency in how things were built, then emerge -e @world doesn't sound like a bad idea


Yeah, I'm still a little stumped about this. Even when building bash with clang the linker pulls in libgomp from gcc. I don't think it's supposed to do that. Gah, emerge -e @world is gonna take forever.
Back to top
View user's profile Send private message
Ionen
Veteran
Veteran


Joined: 06 Dec 2018
Posts: 1111

PostPosted: Fri Jul 24, 2020 4:04 pm    Post subject: Reply with quote

Check other dependencies too, mentioned ncurses but there's also readline. Those could be the ones linked against libgomp which in turn become needed for bash.

Although you may have more things linked against that laying around.. so yeah.
Back to top
View user's profile Send private message
Deathcrow
n00b
n00b


Joined: 24 Jul 2006
Posts: 32

PostPosted: Fri Jul 24, 2020 4:11 pm    Post subject: Reply with quote

Ionen wrote:
Although you may have more things linked against that laying around.. so yeah.


Oh boy, you don't know the half of it. Something is majorly fucked up.

Code:

rockpro64 /etc # ldd /usr/bin/ld.lld                                                                                                                                                                                                    ✘ 130
        linux-vdso.so.1 (0x0000ffffae61b000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000ffffae5a7000)
        libLLVM-10.so => /usr/lib/llvm/10/lib64/libLLVM-10.so (0x0000ffffabf07000)
        libstdc++.so.6 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libstdc++.so.6 (0x0000ffffabc94000)
        libc.so.6 => /lib64/libc.so.6 (0x0000ffffabb2b000)
        /lib/ld-linux-aarch64.so.1 => /lib64/ld-linux-aarch64.so.1 (0x0000ffffae5eb000)
        libffi.so.7 => /usr/lib64/libffi.so.7 (0x0000ffffabb0a000)
        libz.so.1 => /lib64/libz.so.1 (0x0000ffffabad9000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000ffffabac5000)
        libtinfo.so.6 => /lib64/libtinfo.so.6 (0x0000ffffaba73000)
        libm.so.6 => /lib64/libm.so.6 (0x0000ffffab9cb000)
        libgcc_s.so.1 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc_s.so.1 (0x0000ffffab9a6000)
        libgomp.so.1 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgomp.so.1 (0x0000ffffab959000)
rockpro64 /etc # ldd /usr/bin/ld.gold
        linux-vdso.so.1 (0x0000ffff8302a000)
        libz.so.1 => /lib64/libz.so.1 (0x0000ffff82af8000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000ffff82ae4000)
        libstdc++.so.6 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libstdc++.so.6 (0x0000ffff82871000)
        libm.so.6 => /lib64/libm.so.6 (0x0000ffff827c9000)
        libgcc_s.so.1 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc_s.so.1 (0x0000ffff827a4000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000ffff82774000)
        libc.so.6 => /lib64/libc.so.6 (0x0000ffff8260b000)
        /lib/ld-linux-aarch64.so.1 => /lib64/ld-linux-aarch64.so.1 (0x0000ffff82ffa000)
        libgomp.so.1 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgomp.so.1 (0x0000ffff825be000)
rockpro64 /etc # ldd /usr/bin/ld.bfd
        linux-vdso.so.1 (0x0000ffff90d17000)
        libbfd-2.34.0.gentoo-sys-devel-binutils-st.so => /usr/lib64/binutils/aarch64-unknown-linux-gnu/2.34/libbfd-2.34.0.gentoo-sys-devel-binutils-st.so (0x0000ffff90a0c000)
        libctf.so.0 => /usr/lib64/binutils/aarch64-unknown-linux-gnu/2.34/libctf.so.0 (0x0000ffff909e0000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000ffff909b8000)
        libc.so.6 => /lib64/libc.so.6 (0x0000ffff9084f000)
        /lib/ld-linux-aarch64.so.1 => /lib64/ld-linux-aarch64.so.1 (0x0000ffff90ce7000)
        libz.so.1 => /lib64/libz.so.1 (0x0000ffff9081e000)
        libgomp.so.1 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgomp.so.1 (0x0000ffff907d1000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000ffff907a1000)


Yikes! It's everywhere. 8O

Code:

rockpro64 /etc # eix libomp
[I] sys-libs/libomp
     Available versions:  8.0.1^t 9.0.1^t 10.0.0^t **10.0.1_rc1^t **10.0.1_rc2^t **10.0.1_rc3^t **10.0.1_rc4^t (~)10.0.1^t **10.0.1.9999*l^t **11.0.0.9999*l^t **12.0.0.9999*l^t {cuda hwloc offload ompt test ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="linux"}
     Installed versions:  10.0.1^t(02:39:28 PM 07/22/2020)(-cuda -hwloc -offload -ompt -test ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="-32 -64 -x32" KERNEL="linux")
     Homepage:            https://openmp.llvm.org
     Description:         OpenMP runtime library for LLVM/clang compiler

rockpro64 /etc # ldd /usr/lib64/libomp.so
        linux-vdso.so.1 (0x0000ffff9cc86000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000ffff9cb50000)
        libgomp.so.1 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgomp.so.1 (0x0000ffff9cb03000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000ffff9cad3000)
        libc.so.6 => /lib64/libc.so.6 (0x0000ffff9c96a000)
        /lib64/ld-linux-aarch64.so.1 (0x0000ffff9cc56000)

Go home linux, you're drunk! ("I've put some gomp into your omp so that you can better gomp")
Back to top
View user's profile Send private message
Ionen
Veteran
Veteran


Joined: 06 Dec 2018
Posts: 1111

PostPosted: Fri Jul 24, 2020 4:18 pm    Post subject: Reply with quote

libgomp not present on any of those for me :|
Code:
$ ldd /usr/lib64/libomp.so
   linux-vdso.so.1 (0x00007ffff7fd1000)
   libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ffff7e91000)
   libdl.so.2 => /lib64/libdl.so.2 (0x00007ffff7e8c000)
   libc.so.6 => /lib64/libc.so.6 (0x00007ffff7d06000)
   /lib64/ld-linux-x86-64.so.2 (0x00007ffff7fd2000)

.. maybe you've somehow built glibc with it? That would explain why everything has it. Although unless you've been overriding flag-o-matic / custom-cflags that shouldn't have happened
Back to top
View user's profile Send private message
Deathcrow
n00b
n00b


Joined: 24 Jul 2006
Posts: 32

PostPosted: Fri Jul 24, 2020 4:26 pm    Post subject: Reply with quote

Ionen wrote:
libgomp not present on any of those for me :|
Code:
$ ldd /usr/lib64/libomp.so
   linux-vdso.so.1 (0x00007ffff7fd1000)
   libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ffff7e91000)
   libdl.so.2 => /lib64/libdl.so.2 (0x00007ffff7e8c000)
   libc.so.6 => /lib64/libc.so.6 (0x00007ffff7d06000)
   /lib64/ld-linux-x86-64.so.2 (0x00007ffff7fd2000)

.. maybe you've somehow built glibc with it? That would explain why everything has it. Although unless you've been overriding flag-o-matic / custom-cflags that shouldn't have happened


I've definitely messed with glibc custom-cflags before, because I'm a ricer and a masochist. But they are currently turned off... So, no.

Code:

rockpro64 ~ # ldd /lib64/ld-linux-aarch64.so.1 /lib64/libBrokenLocale.so.1 /lib64/libanl.so.1 /lib64/libanl.so.1 /lib64/libc.so.6 /lib64/libcrypt.so.1 /lib64/libdl.so.2 /lib64/libm.so.6 /lib64/libnsl.so.1 /lib64/libnss_compat.so.2 /lib64/libnss_db.so.2 /lib64/libnss_dns.so.2 /lib64/libnss_files.so.2 /lib64/libnss_hesiod.so.2 /lib64/libpthread.so.0 /lib64/libresolv.so.2 /lib64/librt.so.1 /lib64/libthread_db.so.1 /lib64/libutil.so.1 | grep gomp
rockpro64 ~ #     


Small respite, but glibc seems clean.

Thanks for all your help so far... I think I'll take a break from it now and just run emerge -e @system. Maybe that will do something good for me, I'll come back to this later.

Edit: I just learned about lddtree. It is helpful in tracking down this bs:

Code:

rockpro64 packages # lddtree /usr/bin/ld.*
/usr/bin/ld.bfd (interpreter => /lib/ld-linux-aarch64.so.1)
    libbfd-2.33.1.gentoo-sys-devel-binutils-st.so => /usr/lib64/binutils/aarch64-unknown-linux-gnu/2.33.1/libbfd-2.33.1.gentoo-sys-devel-binutils-st.so
        libz.so.1 => /lib64/libz.so.1
            libgomp.so.1 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgomp.so.1
                libpthread.so.0 => /lib64/libpthread.so.0
    libdl.so.2 => /lib64/libdl.so.2
    libc.so.6 => /lib64/libc.so.6
/usr/bin/ld.gold (interpreter => /lib/ld-linux-aarch64.so.1)
    libz.so.1 => /lib64/libz.so.1
        libgomp.so.1 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgomp.so.1
    libdl.so.2 => /lib64/libdl.so.2
    libstdc++.so.6 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libstdc++.so.6
        libm.so.6 => /lib64/libm.so.6
    libgcc_s.so.1 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc_s.so.1
    libpthread.so.0 => /lib64/libpthread.so.0
    libc.so.6 => /lib64/libc.so.6
/usr/bin/ld.lld (interpreter => /lib/ld-linux-aarch64.so.1)
    libpthread.so.0 => /lib64/libpthread.so.0
    libLLVM-10.so => /usr/lib/llvm/10/lib64/libLLVM-10.so
        libffi.so.7 => /usr/lib64/libffi.so.7
        libz.so.1 => /lib64/libz.so.1
            libgomp.so.1 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgomp.so.1
        libdl.so.2 => /lib64/libdl.so.2
        libtinfo.so.6 => /lib64/libtinfo.so.6
        libm.so.6 => /lib64/libm.so.6
        libgcc_s.so.1 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc_s.so.1
    libstdc++.so.6 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libstdc++.so.6
    libc.so.6 => /lib64/libc.so.6
rockpro64 packages # lddtree /bin/bash
/bin/bash (interpreter => /lib/ld-linux-aarch64.so.1)
    libreadline.so.8 => /lib64/libreadline.so.8
        libtinfow.so.6 => /lib64/libtinfow.so.6
            libgomp.so.1 => /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgomp.so.1
                libdl.so.2 => /lib64/libdl.so.2
                libpthread.so.0 => /lib64/libpthread.so.0
    libc.so.6 => /lib64/libc.so.6
Back to top
View user's profile Send private message
Ionen
Veteran
Veteran


Joined: 06 Dec 2018
Posts: 1111

PostPosted: Fri Jul 24, 2020 4:54 pm    Post subject: Reply with quote

I "think" clang used to use libgomp by default for openmp, but pretty sure that's a thing of the past.
Code:
$ clang-10 -o test test.c; ldd test | grep omp
$ clang-10 -fopenmp -o test test.c; ldd test | grep omp
   libomp.so => /usr/lib64/libomp.so (0x00007ffff7eb2000)
$ clang-10 -fopenmp=libgomp -o test test.c; ldd test | grep omp
   libgomp.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libgomp.so.1 (0x00007ffff7f7a000)
Well, good luck tracking this down :) (and yeah, despite being on ~testing I'm still not using gcc10.. probably switch soon'ish now that 10.2 is out, and that's why this thread caught my interest for potential issues)
Back to top
View user's profile Send private message
Deathcrow
n00b
n00b


Joined: 24 Jul 2006
Posts: 32

PostPosted: Fri Jul 24, 2020 5:15 pm    Post subject: Reply with quote

Good news! I think I figured it out. The culprit is... drum-roll: -ftree-parallelize-loops=4

This seems to add a hard dependency for libgomp to... everything, for example zlib or ncurses, which affects everything, even if you use conservative CFLAGS for bash or coreutils. Remember kids: Don't talk to strange CFLAGs that you find online and don't get in their cars. :roll: Oh and maybe start using safe cflags for everything that's really important.

The moral of this story: I deserve this.
Back to top
View user's profile Send private message
Ionen
Veteran
Veteran


Joined: 06 Dec 2018
Posts: 1111

PostPosted: Fri Jul 24, 2020 5:25 pm    Post subject: Reply with quote

I did suspect there could be other flags (from my first reply), I vaguely remembered reading about this :) Well glad to hear figured it out.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46103
Location: 56N 3W

PostPosted: Fri Jul 24, 2020 5:33 pm    Post subject: Reply with quote

Moved from Portage & Programming to Gentoo on ARM.

aarcch64 says that it belongs here.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM 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