Hi Kib,
On Mon, Sep 27, 2010 at 06:44:57PM +0300, Kostik Belousov wrote:
> Hardcoding /usr/lib as the path to the library in the script looks
> problematic. For the buidlworld, you are linking resulting binaries
> with the host library, instead of the buildworld-produced one. For
> lib32, it makes non-working combination of 32/64 bit.
Sorry for the late reply, but I had to collect various evidences for my
sayings and my development machine is reaaaaaaaaaaally slow.
In fact it seems the toolchain built for buildworld contains a ld(1)
binary which invariably bases lookups for libraries in ${WORLDTMP}, even
in case of an absolute path. I have two evidences of this:
- Putting /usr/obj/usr/src/tmp/usr/lib/libssp_nonshared.a in
/usr/obj/usr/src/tmp/usr/lib/libc.ld leads toolchain's ld(1) to use
/usr/obj/usr/src/tmp/usr/obj/usr/src/tmp/usr/lib/libssp_nonshared.a;
- I also verified this with a hand-wrought opensnoop-like DTrace script.
If it's enough for you, can you please go forward and commit my patch?
I can make a cleaner one if you want.
Thanks.
Regards,
--
Jeremie Le Hen
Humans are born free and equal. But some are more equal than others.
Coluche
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
