[PATCH] pkgmk.in: Fix to remove hardcoded framework path in .la files
- find $PKG -type f -name '*.la' -exec sed "s|$CLFS||g" -i {} \; + find $PKG -type f -name '*.la' -exec sed -e "s|$CLFS||g" -e "s|$CROSTOOLS/$CTARGET|/usr|g" -i {} \; } check_footprint() {
- find $PKG -type f -name '*.la' -exec sed "s|$CLFS||g" -i {} \; + find $PKG -type f -name '*.la' -exec sed -e "s|$CLFS||g" -e "s|$CROSTOOLS/$CTARGET|/usr|g" -i {} \; }
check_footprint() { good! +1
Hi Victor, On 06/07/10 14:48, Victor@crux-arm.nu wrote: this patch is required to avoid this situations on the target device that could break native compilations: $ grep -i crosstools /usr/lib/libgmpxx.la dependency_libs=' /usr/lib/libgmp.la /devel/crux-arm/toolchain-noeabi/crosstools/arm-crux-linux-gnu/lib/libstdc++.la' and IMHO this causes to postpone RC5, so we need to regenerate at least all core packages to cleanup their .la files Best regards, -- Jose V Beneyto | http://sepen.mine.nu/
* Jose V Beneyto (sepen@crux-arm.nu) wrote:
Hi Victor,
On 06/07/10 14:48, Victor@crux-arm.nu wrote:
- find $PKG -type f -name '*.la' -exec sed "s|$CLFS||g" -i {} \; + find $PKG -type f -name '*.la' -exec sed -e "s|$CLFS||g" -e "s|$CROSTOOLS/$CTARGET|/usr|g" -i {} \; }
check_footprint() { good! +1 Great, thank you for the feedback Jose.
this patch is required to avoid this situations on the target device that could break native compilations:
$ grep -i crosstools /usr/lib/libgmpxx.la dependency_libs=' /usr/lib/libgmp.la /devel/crux-arm/toolchain-noeabi/crosstools/arm-crux-linux-gnu/lib/libstdc++.la'
and IMHO this causes to postpone RC5, so we need to regenerate at least all core packages to cleanup their .la files +1 This is what I was thinking this last weekend. Finding and fixing things bit by bit. And the ones related to native builds will appear slowly.
There is another thing that seems to don't hurt (may be there is a lack of knowledge from my side atm), for example: [pitillo@safe-env /des/crux-arm/toolchain/clfs/usr/lib]$ objdump -x libstdc++.so|grep RPATH RPATH /des/crux-arm/toolchain/crosstools/arm-crux-linux-gnueabi/lib This means that libtool will try on native builds to locate this path, but it doesn't exists and it will not be used.
Best regards,
Regards.
-- Jose V Beneyto | http://sepen.mine.nu/
_______________________________________________ crux-arm mailing list crux-arm@crux-arm.nu http://crux-arm.nu/mailman/listinfo/crux-arm
--- Learning bit by bit Victor Martinez | http://lokalix.dyndns.org
Hey Victor, On 06/08/10 10:44, pitillo@crux-arm.nu wrote:
[...] There is another thing that seems to don't hurt (may be there is a lack of knowledge from my side atm), for example:
[pitillo@safe-env /des/crux-arm/toolchain/clfs/usr/lib]$ objdump -x libstdc++.so|grep RPATH RPATH /des/crux-arm/toolchain/crosstools/arm-crux-linux-gnueabi/lib
This means that libtool will try on native builds to locate this path, but it doesn't exists and it will not be used. yeah but seems that this is not a problem: [1]
"...ELF binaries (used by Solaris and Linux) can contain in the binary supplemental paths for shared libraries ... This path is searched before the system default paths (but is overridden by LD_LIBRARY_PATH, if set)..." anyways I'd like to cleanup binaries whenever be possible and we should take when we're building a port to see if a solution could be applied, or at least we should write a patch for pkgutils-cross to remove this rpath stuff from elf generated binaries like patchelf [2] does. Best regards, [1] http://www.eyrie.org/~eagle/notes/rpath.html [2] http://nixos.org/patchelf.html -- Jose V Beneyto | http://mikeux.dyndns.org
Hi again, On 06/10/10 09:06, Jose V Beneyto wrote:
Hey Victor,
On 06/08/10 10:44, pitillo@crux-arm.nu wrote:
[...] There is another thing that seems to don't hurt (may be there is a lack of knowledge from my side atm), for example:
[pitillo@safe-env /des/crux-arm/toolchain/clfs/usr/lib]$ objdump -x libstdc++.so|grep RPATH RPATH /des/crux-arm/toolchain/crosstools/arm-crux-linux-gnueabi/lib
This means that libtool will try on native builds to locate this path, but it doesn't exists and it will not be used. [...]
some tests I made: $ export PATH=$PATH:/devel/crux-arm/toolchain/crosstools/bin $ unset CFLAGS; unset CXXFLAGS; unset CC $ cat > test.c #include <stdio.h> int main(int argc, char ** argv) { printf("CRUX ARM Test\n"); return 0; } $ arm-crux-linux-gnu-gcc -Wall -o test test.c $ arm-crux-linux-gnu-objdump -x test | grep -i rpath $ arm-crux-linux-gnu-gcc -Wall -Wl,-rpath,/usr/lib -o test2 test.c $ arm-crux-linux-gnu-objdump -x test2 | grep -i rpath RPATH /usr/lib $ arm-crux-linux-gnu-gcc -Wall -Wl,-rpath,/devel/crux-arm/crosstools/lib -o test3 test.c $ arm-crux-linux-gnu-objdump -x test3 | grep -i rpath RPATH /devel/crux-arm/crosstools/lib seems that in cross-generated packages just we need to look for and cleanup flags containing rpath, so there are some with LDFLAGS="-Wl,-rpath,$(CROSSTOOLS)/lib": $ find ports/ -type f -name Pkgfile -exec grep -H -i rpath {} \; | cut -d':' -f1 ports/opt-cross/irssi/Pkgfile ports/opt-cross/navit/Pkgfile ports/opt-cross/libmpeg2/Pkgfile ports/games-cross/opentyrian/Pkgfile ports/games-cross/prboom/Pkgfile ports/games-cross/xmoto/Pkgfile ports/core-cross-noeabi/gcc/Pkgfile <--------- most important for what I know we should keep rpath only for the toolchain and not for production packages Regards, -- Jose V Beneyto | http://mikeux.dyndns.org
participants (3)
-
Jose V Beneyto -
pitillo＠crux-arm.nu -
Victor Martinez