Bug 361465 – sys-apps/openrc-0.8.0: cross-compilation fails due to -L/lib hardcode

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Guillaume ZITTA 2011-03-31 11:51:16 UTC]

crosscompiling (crossdev) openrc to arm from amd64, build fail :
/lib/libgcc_s.so.1: file not recognized: File format not recognize

Reproducible: Always

Steps to Reproduce:
1.crosscompile openrc with a different arch from the host
2.
3.
Actual Results:  
/lib/libgcc_s.so.1: file not recognized: File format not recognized
collect2: ld a retourné 1 code d'état d'exécution


Expected Results:  
compile

[Comment 1 Guillaume ZITTA 2011-03-31 11:51:43 UTC]

Created attachment 267971 [details]
Build log

[Comment 2 Guillaume ZITTA 2011-03-31 11:52:13 UTC]

Created attachment 267973 [details, diff]
patch for the ebuild

[Comment 3 William Hubbs 2011-03-31 17:45:20 UTC]

This fix would work for gentoo systems  but no one else. I'm wondering
if there is a way we can work this into openrc's build system so that
others who use openrc can benefit from the fix?

[Comment 4 SpanKY 2011-03-31 19:17:58 UTC]

Comment on attachment 267973 [details, diff]
patch for the ebuild

ROOT is never valid in src_* funcs let alone in the build system itself

if openrc is adding random hardcoded -L flags, that needs to be fixed.

[Comment 5 SpanKY 2011-03-31 19:18:46 UTC]

p

[Comment 6 Guillaume ZITTA 2011-04-01 11:25:24 UTC]

(In reply to comment #4)
 
> ROOT is never valid in src_* funcs let alone in the build system itself
Why ? baselayout ebuild has $ROOT in src_install ...

> 
> if openrc is adding random hardcoded -L flags, that needs to be fixed.
desktop openrc-0.8.0 # grep -r '\-L' mk/lib.mk
LDFLAGS+=	-L/${LIBNAME} -Wl,-rpath=/${LIBNAME}

It's seems not hardcoded nor random, it's the ebuild that sets LIBNAME

Excuse me if I seems to challenge you, but I'd like to understand.

[Comment 7 SpanKY 2011-04-01 20:39:26 UTC]

baselayout has exactly one ROOT check and it's fairly trivial.  but it's still wrong and needs to be fixed.

seems to me it is hardcoded and random.  the .mk code shouldnt be doing that since there's no real need for it.

[Comment 8 William Hubbs 2011-04-01 21:49:34 UTC]

Created attachment 268153 [details]
fix-libpath.patch

Applying this patch, which removes the -L and -rpath options from
ldflags doesn't cause any issues for me.

Mike, is this what we would want to do to fix the issue?

[Comment 9 SpanKY 2011-04-01 22:16:49 UTC]

makes sense to me.  if someone comes up with a case where they need the -L/-rpath, we can revisit then to figure out why exactly their system isnt working as it should.

[Comment 10 William Hubbs 2011-04-01 22:45:52 UTC]

This has been applied, commit 67640d2.

Thanks for the report.