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
Created attachment 267971 [details] Build log
Created attachment 267973 [details, diff] patch for the ebuild
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 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.
p
(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.
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.
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?
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.
This has been applied, commit 67640d2. Thanks for the report.
