Bug 812698 – dev-util/meson: LD_LIBRARY_PATH set in the environment overrides DT_RUNPATH on binaries invoked during builds (x11-misc/colord-1.4.5-r1 fails to build with "undefined symbol: cd_icc_set_created")

• Status: UNCONFIRMED
• Product: Gentoo Linux

[Description Jared B. 2021-09-12 00:01:11 UTC]

I cannot build colord-1.4.5-r1.  Multiple build attempts fail.  It seems to be failing at this step:

[102/200] /tmp/portage/x11-misc/colord-1.4.5-r1/work/colord-1.4.5-abi_x86_64.amd64/client/cd-create-profile --output=data/profiles/AdobeRGB1998.icc data/profiles/AdobeRGB1998.iccprofile.xml
FAILED: data/profiles/AdobeRGB1998.icc
/tmp/portage/x11-misc/colord-1.4.5-r1/work/colord-1.4.5-abi_x86_64.amd64/client/cd-create-profile --output=data/profiles/AdobeRGB1998.icc data/profiles/AdobeRGB1998.iccprofile.xml
/tmp/portage/x11-misc/colord-1.4.5-r1/work/colord-1.4.5-abi_x86_64.amd64/client/cd-create-profile: symbol lookup error: /tmp/portage/x11-misc/colord-1.4.5-r1/work/colord-1.4.5-abi_x86_64.amd64/client/cd-create-profile: undefined symbol: cd_icc_set_created
ninja: build stopped: subcommand failed.

I've not had any luck troubleshooting myself.  Attaching build logs.

Reproducible: Always

Steps to Reproduce:
1. emerge -v colord
2. wait



I currently have colord 1.3.5, so technically this is an upgrade.  Don't believe that's relevant, but including just in case.

[Comment 1 Jared B. 2021-09-12 00:04:33 UTC]

Created attachment 738946 [details]
emerge --info

[Comment 2 Jared B. 2021-09-12 00:04:49 UTC]

Created attachment 738949 [details]
emerge -pqv

[Comment 3 Jared B. 2021-09-12 00:09:28 UTC]

Created attachment 738952 [details]
build log

[Comment 4 Sam James 2021-09-12 00:23:09 UTC]

Given you filed bug 812701 too, this seems a bit odd.

Could you try with a different PORTAGE_TMPDIR? Ideally just the default (unset it, i.e. /var/tmp/portage)? Certain things may break when using a tmpfs (even if they shouldn't).

Is there anything else interesting about your system?

[Comment 5 Jared B. 2021-09-12 02:30:04 UTC]

I agree it's odd.  I've actually been having this issue for at least a couple months at this point - have been using --keep-going to get the rest of my updates.

I just tried commenting out PORTAGE_TMPDIR in make.conf, but still get the same problem.  Also verified /var/tmp/portage is not mounted under tmpfs.

I've spent a fair amount of time previously troubleshooting this - rebuilding related packages, ninja, gcc, etc. to try to get those undefined symbols, well, defined, but I've had zero luck.

I do have a fairly complex portage setup, leveraging several package.* files and whatnot to tweak my system, but nothing that I can think would relate to these particular packages.  I do have ABI_X86="64 32" enabled for colord (due to some dependency I can no longer remember), which probably counts as interesting, but not for appstream.  Aside from that...  it's a mostly stable amd64 system with select ~amd64 packages and fairly extensive tweaked US flags.

Happy to provide any additional info that may help.  Heck, happy to move this to the forum or something as well if you think this may be an issue with my particular system and not appropriate for bugzilla.  Just getting pretty desperate to get this resolved at this point.

[Comment 6 Sam James 2021-09-12 02:33:49 UTC]

(In reply to Jared B. from comment #5)
> I agree it's odd.  I've actually been having this issue for at least a
> couple months at this point - have been using --keep-going to get the rest
> of my updates.
> 

My only observations so far:
- both bugs seem to be similar (they're Meson and they're invoking a binary to generate something which fails, it's not a compile failure per-se);
- they both seem to be https://github.com/mesonbuild/meson/issues/2881 / https://github.com/mesonbuild/meson/issues/1635.

> I just tried commenting out PORTAGE_TMPDIR in make.conf, but still get the
> same problem.  Also verified /var/tmp/portage is not mounted under tmpfs.
> 

Thanks.

> 
> I do have a fairly complex portage setup, leveraging several package.* files
> and whatnot to tweak my system, but nothing that I can think would relate to
> these particular packages.  I do have ABI_X86="64 32" enabled for colord
> (due to some dependency I can no longer remember), which probably counts as
> interesting, but not for appstream.  Aside from that...  it's a mostly
> stable amd64 system with select ~amd64 packages and fairly extensive tweaked
> US flags.

(That is fine in general, ofc, that's what Gentoo's for ;))

Any package.env and env stuff I should know about?

Can you also try with a clean environment for me?

i.e. su -i and try again?

> 
> Happy to provide any additional info that may help.  Heck, happy to move
> this to the forum or something as well if you think this may be an issue
> with my particular system and not appropriate for bugzilla.  Just getting
> pretty desperate to get this resolved at this point.

I'm always around in #gentoo on libera.chat and happy to dive into such things. Tempted to say let's go there if you're willing, and then circle back to the bug(s) if we can find something solid to put in them?

It's a lot easier for me to ask random questions (and for others to) and come up with ideas then.

[Comment 7 Sam James 2021-09-12 02:54:09 UTC]

My suggestion for now is that we unset LD_LIBRARY_PATH in the eclass, but not thought about any better solutions yet.

[Comment 8 Sam James 2021-09-12 02:54:23 UTC]

*** Bug 812701 has been marked as a duplicate of this bug. ***

[Comment 9 Mike Gilbert 2021-09-12 03:24:33 UTC]

How have you reached the conclusion that this is related to LD_LIBRARY_PATH? I don't see that mentioned in any of the previous bug comments. 

Also, I'm unable to reproduce this issue by setting LD_LIBRARY_PATH=/x when running emerge.

[Comment 10 Mike Gilbert 2021-09-12 03:29:03 UTC]

Ok, I see this conclusion was reached via a conversion in #gentoo on IRC.

I don't like the idea of un-setting LD_LIBRARY_PATH in meson.eclass. This should either be fixed upstream, or not at all.