Re: [lfs-dev] multilib book SVN-20190327
Am Dienstag, den 16.04.2019, 20:00 +0100 schrieb spiky0011 via lfs- dev: > Hello > > Just going through multilib book > > at ch5.7 glibc running sanity check for -mx32 > > I get wrong output > > [Requesting program interpreter: /tools/libx32/ld-linux-x32.so.2] > > not > > [Requesting program interpreter: /tools/lib/ld-linux-x32.so.2] > > ls -l tools/lib/ld-linux-x32.so.2 > > tools/lib/ld-linux-x32.so.2 -> /tools/libx32/ld-linux-x32.so.2 > > I have rebuilt from scratch a couple of times but always the same output? > > The 64 part is ok and the -m32 is ok. > > All commands were copy & paste. > Thanks for reporting this. That was a copy&paste error. Sorry that you had to waste some (cpu-)seconds with that. I fixed that along with a merge of upstream changes. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Our perl builds are not hardened
I was looking through my logs to identify which packages do not use my CFLAGS, CXXFLAGS (thinking about trying LTO at some point) and reading the voluminous output from perl's Configure I noticed: Guessing which symbols your C compiler and preprocessor define... You seem not to have gcc 4.* or later, not adding -D_FORTIFY_SOURCE. That is because 5.28.1 has the following: case "$gccversion" in [4567].*) case "$optimize$ccflags" in Using sed -i 's/^\(\[4567\)/\18/' Configure gives me Guessing which symbols your C compiler and preprocessor define... Adding -D_FORTIFY_SOURCE=2 to ccflags... ĸen -- It is said that there are two great unsolved problems in computer science: naming, cache invalidation, and off-by-one errors. -- Ben Bullock -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Python3 in LFS: but no bare python exectuable.
On Tue, 16 Apr 2019 at 15:07, Pierre Labastie via lfs-dev wrote: > > I think linking python->python3 is a bit premature. We should do that when > upstream python does, or most packages expect it, but not only one. ATM, a lot > of packages, which can accept P3, can still accept python2.7, and expect > python to point to python2.7. And packages bound to P2 expect usually python > to point to python2.x. That may change within a year or so (when P2 is not > maintained anymore). > > Pierre I think that's probably the right approach, and indeed, from my understanding of what the Xen folk have done, they have brought some older Python 2 scripts up to a level where Python 3 can run them, as opposed to creating Python 3-only scripts. Having said that, my attempts to build Xen with just a python3 binary do appear to have brought some Python-related issues to the surface for the Xen developers, so attempting to build it under LFS has been useful in exposing some of the assumptions they have been making, even if they could get away with things if a "bare python" existed. Kevin -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
