Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 675368

Summary: sys-fs/lvm2-2.02.145 - /usr/libexec/gcc/aarch64-unknown-linux-musl/ld: ../../libdm/libdevmapper.so: undefined reference to `rpl_malloc'
Product: Gentoo Linux Reporter: hanetzer
Component: Current packagesAssignee: Gentoo's Team for Core System packages <base-system>
Status: UNCONFIRMED ---    
Severity: normal CC: agk, cardoe, lucas.yamanishi, robbat2
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=762017
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: build.log
aarch64-unknown-linux-musl-emerge --info
emerge --info (native aarch64-unknown-linux-gnu)
x86_64-unknown-linux-musl config.log
x86_64-unknown-linux-musl build.log
x86_64-unknown-linux-musl emerge --info

Description hanetzer 2019-01-14 00:52:02 UTC
Unsure if this is actually common to all hardware, trying some other flavors
as I write this, but on a gentoo aarch64-unknown-linux-gnu system emerging
sys-fs/lvm2::musl with an aarch64-unknown-linux-musl cross-toolchain the build
fails with undefined references to rpl_malloc and rpl_realloc

A fix/workaround I've found is to set (either in the ebuild's src_configure
or via pkg.env) ac_cv_func_malloc_0_nonnull=yes and ac_cv_func_realloc_0_nonnull=yes

Unsure where such a fix should be made, either in sys-devel/crossdev's site
files or maybe in the ebuild itself (I've seen it/similar hacks in a lot of
in-tree ebuilds).

Other info inbound as I un'fix' it and rerun builds to capture logs and such.
Comment 1 hanetzer 2019-01-14 01:07:24 UTC
Created attachment 560930 [details]
build.log
Comment 2 hanetzer 2019-01-14 01:09:55 UTC
Created attachment 560932 [details]
aarch64-unknown-linux-musl-emerge --info
Comment 3 hanetzer 2019-01-14 01:11:28 UTC
Created attachment 560934 [details]
emerge --info (native aarch64-unknown-linux-gnu)
Comment 4 Sergei Trofimovich gentoo-dev 2019-01-14 07:24:35 UTC
I guess it would help to see config.log if it's dependent on ./configure output.
My guess would be that
    checking for GNU libc compatible malloc... no
is a relevant piece.
Comment 5 hanetzer 2019-01-14 08:23:58 UTC
(In reply to Sergei Trofimovich from comment #4)
> I guess it would help to see config.log if it's dependent on ./configure
> output.
> My guess would be that
>     checking for GNU libc compatible malloc... no
> is a relevant piece.

Exact same failure on an x86_64-pc-linux-gnu->x86_64-pc-linux-musl cross
Comment 6 dkjii 2021-02-04 00:29:16 UTC
Created attachment 685725 [details]
x86_64-unknown-linux-musl config.log
Comment 7 dkjii 2021-02-04 00:29:39 UTC
Created attachment 685728 [details]
x86_64-unknown-linux-musl build.log
Comment 8 dkjii 2021-02-04 00:33:46 UTC
Created attachment 685731 [details]
x86_64-unknown-linux-musl emerge --info
Comment 9 dkjii 2021-02-04 00:34:09 UTC
(In reply to hanetzer from comment #5)
> (In reply to Sergei Trofimovich from comment #4)
> > I guess it would help to see config.log if it's dependent on ./configure
> > output.
> > My guess would be that
> >     checking for GNU libc compatible malloc... no
> > is a relevant piece.
> 
> Exact same failure on an x86_64-pc-linux-gnu->x86_64-pc-linux-musl cross

Same issue here, added some attachments