Re: [lfs-dev] Doubled instruction in Binutils Pass2 in Multilib book
Am Sonntag, dem 21.03.2021 um 10:39 +0800 schrieb Kevin Buckley via lfs-dev: > Revision 12166 > > chapter06/binutils-pass2.xml > > has > > Compile the package: > > make > > Install the package, and > workaround an issue causing > libctf.so > to link against zlib from the host distribution: > > make DESTDIR=$LFS install > install -vm755 libctf/.libs/libctf.so.0.0.0 $LFS/usr/lib > > > Workaround an issue causing > libctf.so > to link against zlib from the host distribution: > > > install -vm755 > libctf/.libs/libctf.so.0.0.0 $LFS/usr/lib > > The second and pair appear to duplicate the first, which is > all the vanilla book has. > > Kevin Oops, thanks! Will remove the extra instructions -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib Chapter 5 zlib: configure maybe missing --host flag
Am Samstag, den 14.11.2020, 10:04 +0100 schrieb Pierre Labastie via lfs-dev: > On Sat, 2020-11-14 at 10:45 +0800, Kevin Buckley via lfs-dev wrote: > > On Fri, 13 Nov 2020 at 09:29, Kevin Buckley > > wrote: > > > > > > Hi Thomas, > > > > > > I believe that, as of Revision: 12059, your Zlib section in Chapter > > > 5 > > > is missing the "--host=$LFS_TGT" flag > > > > > > Compare > > > > > > Prepare Zlib for compilation: > > > > > > ./configure > > > --prefix=/usr > > > > > > Compile the package: > > > > > > > > > with the corresponding XML from the GZip section > > > > > > > > > Prepare Gzip for compilation: > > > > > > ./configure --prefix=/usr > > > --host=$LFS_TGT > > > > > > Compile the package: > > > > > > > > > When I came to build the Zlib, I ended up getting an error from the > > > host compiler > > > and it took me a while to work out why the build wasn't using the > > > compiler in > > > $LFS/tools/bin. > > > > > > It is also possible that the 32-bit and x32 build instructions for > > > Zlib are missing the > > > $LFS_TGT in their CC configure overrides that ones sees in the > > > Chapter 5 Ncurses > > > > > > zlib.xml:CC="gcc -m32" \ > > > zlib.xml:CC="gcc -mx32" \ > > > > > > Cf > > > > > > ncurses.xml:CC="$LFS_TGT-gcc > > > -m32" \ > > > ncurses.xml:CC="$LFS_TGT-gcc > > > -mx32" \ > > > > > > Hoping that helps, and thanks again for the Mulitlib additions, > > > Kevin > > > > > > What I have since discovered is that the Configure script for Zlib > > doesn't > > accept the --host= argument, hence, I guess, the use of the CC= > > constructs > > in the Multilib stanzas. > > > > With that in mind, the x86_64 configure probably needs to be marked > > up as > > > > CC="$LFS_TGT-gcc" \ > > ./configure --prefix=/usr > > > > so as to enforce the use of the compiler in /tools/bin. > > Actually, I'm amazed to see zlib in chapter 6 of the multilib book. In > the pure x86_64 (or i686) book, it is not built there at all (only in > chapter 8). > > Thomas, do you remember why it was added there (was on June 29th)? > Have to check that. I think it was introduced in former versions of the ML-book. I'll leave that out in chap6 for a test to see whats happening... -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Adding attributes in the source XML
Am Dienstag, den 06.10.2020, 18:48 +0800 schrieb Kevin Buckley via
lfs-dev:
> i was experimenting with making use of an extra attribute in the
> XML source tags, akin to the vanilla book's 'sysv' or 'systemd'
> for the "revision" attribute,, or to Thomas's Multilib arch attribute
> ('ml_32', 'ml_x32' or 'ml_all').
>
> When i come to render my source, having added an extra
> stringparam to the xsltproc invocations, vis
>
> --stringparam profile.revision $(REV) \
> --stringparam profile.arch $(ARCH)\
> --stringparam profile.pkguser $(PKGUSER)\
>
> I get told
>
> validity error : No declaration for attribute pkguser of element
>
> I realise that I have missed adding such a declaration into one of the
> stylesheet, or other ancillary, files but I can't determine, by inspection
> of many of those files, where such a declaration needs to go.
>
> Where should such a declaration go?
Those attributes like 'arch', 'revision' etc. are defined somewhere in
the deepness of docbook. You cannot simply introduce new ones by
adding them to the string parameter list for the renderer. All the
attributes used in the {B,}LFS-book are predefined ones.
You may have allready seen the pages at
http://www.sagehill.net/docbookxsl/AddProfileAtt.html - the talk about
"how easy it is to add". Well, i didn't find it that easy, maybe you
have more luck.
--
Thomas
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Chapter 8 Multilib Libffi x32-bit section title has Libtool entity
Am Samstag, den 25.07.2020, 14:11 +0800 schrieb Kevin Buckley via lfs- dev: > Well I assume it does, given that the rendered version > of r12003 I have just produced says > > 8.48.2. Installation of Libffi - 32bit > > but then > > 8.48.3. Installation of Libtool - x32bit > > Actually, no, it's not the wrong entity, the section titles have the Package > names written in directly, so chapter08/libffi.xml does currently say > > > > > > > Installation of Libtool - x32bit > > Kevin Oops, must have been a copy-paste-error. Will be fixed in the next update. Thanks for reporting. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] perl install options
Am Samstag, den 20.06.2020, 14:53 +0100 schrieb Ken Moffat via lfs- dev: > On Sat, Jun 20, 2020 at 02:42:03PM +0200, Thomas Trepl via lfs-dev wrote: > > Hi all, > > > > this is about hte configuration options of perl. > > > > Problem: > > whenever perl is upgraded to a newer version (for example 5.30.2 to > > 5.30.3), all perl modules needs to be reinstalled as the current > > configuration of perl forces a directory structure like > > > > > > All modules are installed under /usr/lib/perl5/5.30.2 . Now, when > > installing a newer patch-version by overwriting the existing one, the > > structure looks like > > > > > > The 5.30.2-directory (which includes the modules) is more or less > > garbage as the new perl will use 5.30.3. Therefore, any installed > > module must be reinstalled to appear in the 5.30.3 structure. > > > > This all is not really a problem as long as the system is completely > > built from scratch and all modules are installed freshly. For those > > who uses some kind of pkgmnr or upgrade the system package by package > > it might be a problem when perl is about to upgrade. > > > > Yes, for my own systems I have had to rebuild all the modules if > upgrading perl. > > > Suggestion: > > The following is under the assumption that patch-versions of perl are > > compatible to each other. To solve the upgrade issue described above, > > add a few new options to the perl install command in the LFS book: > > > > sh Configure -des \ > > -Dprefix=/usr \ > > - > > Dvendorprefix=/usr \ > > * -Dprivlib=/usr/share/perl5/core_perl > > \ > > * -Darchlib=/usr/lib/perl5//core_perl \ > > * - > > Dsitelib=/usr/share/perl5/site_perl \ > > * - > > Dsitearch=/usr/lib/perl5//site_perl \ > > * - > > Dvendorlib=/usr/share/perl5/vendor_perl \ > > * - > > Dvendorarch=/usr/lib/perl5//vendor_perl \ > > - > > Dman1dir=/usr/share/man/man1 \ > > -Dman3dir=/usr/share/man/man3 \ > > - > > Dpager="/usr/bin/less -isR" \ > > -Duseshrplib \ > > - > > Dusethreads > > > > assuming that we have in packages.ent: > > > > > > > > > > > > > minor;."> > > > > This will produce a directory structure: > > > > /usr > > /lib > > /perl5 > > /5.30 > > /core_perl > > /... > > /site_perl > > /... > > > > where modules are installed under /usr/lib/perl5/5.30/site_perl/ . In > > this case, overwriting the installed perl with a newer one has no > > effect on the installed modules unless minor or even major version of > > perl > > > Sounds nice. But just to be clear - under site_perl I have a > versioned directory (e.g. 5.30.2 for your current example). I > assume, or hope, that will either be 5.30 or completely omitted. This versioned subdir will be omitted completely. Files from XML::Parser are installed as usr/lib/perl5/5.30/site_perl/auto usr/lib/perl5/5.30/site_perl/auto/XML usr/lib/perl5/5.30/site_perl/auto/XML/Parser usr/lib/perl5/5.30/site_perl/auto/XML/Parser/.packlist usr/lib/perl5/5.30/site_perl/auto/XML/Parser/Expat usr/lib/perl5/5.30/site_perl/auto/XML/Parser/Expat/Expat.so usr/lib/perl5/5.30/site_perl/XML usr/lib/perl5/5.30/site_perl/XML/Parser usr/lib/perl5/5.30/site_perl/XML/Parser/Encodings usr/lib/perl5/5.30/site_perl/XML/Parser/Style usr/lib/perl5/5.30/core_perl usr/lib/perl5/5.30/core_perl/perllocal.pod net-ssleay installs as ... usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/randomize.al usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/do_httpx2.al usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/put_https3.al usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/do_https3.al usr/lib/perl5/5.30/site_perl/Net usr/lib/perl5/5.30/site_perl/Net/SSLeay.pod usr/lib/perl5/5.30/site_perl/Net/SSLeay usr/lib/perl5/5.30/site_perl/Net/SSLeay/Handle.pm usr/lib/perl5/5.30/site_perl/Net/SSLeay.pm ... > > i.e. /usr/lib/perl5/5.30/site_perl/5.30/ or > /usr/lib/perl5/5.30/site_perl/ for the directory where 'top level' > modules SGMLS.pm and URI.pm live ? URI: usr/share/perl5/site_perl/URI.pm this pkg seems to use the "sitelib" instead of "sitearch" configuration target. Any info why/when this target is used? > > A note to "make install" might be required as perl refuses to > > overwrite an installation in case of an version mismatch (which makes > > sense in case of incompatible version, maybe when minor or major > > version changes).
[lfs-dev] perl install options
Hi all,
this is about hte configuration options of perl.
Problem:
whenever perl is upgraded to a newer version (for example 5.30.2 to
5.30.3), all perl modules needs to be reinstalled as the current
configuration of perl forces a directory structure like
/usr
/lib
/perl5
/5.30.2
/...
/site_perl
All modules are installed under /usr/lib/perl5/5.30.2 . Now, when
installing a newer patch-version by overwriting the existing one, the
structure looks like
/usr
/lib
/perl5
/5.30.2
/...
/5.30.3
/...
/site_perl
The 5.30.2-directory (which includes the modules) is more or less
garbage as the new perl will use 5.30.3. Therefore, any installed
module must be reinstalled to appear in the 5.30.3 structure.
This all is not really a problem as long as the system is completely
built from scratch and all modules are installed freshly. For those
who uses some kind of pkgmnr or upgrade the system package by package
it might be a problem when perl is about to upgrade.
Suggestion:
The following is under the assumption that patch-versions of perl are
compatible to each other. To solve the upgrade issue described above,
add a few new options to the perl install command in the LFS book:
sh Configure -des \
-Dprefix=/usr \
-
Dvendorprefix=/usr \
* -Dprivlib=/usr/share/perl5/core_perl
\
* -Darchlib=/usr/lib/perl5//core_perl \
* -
Dsitelib=/usr/share/perl5/site_perl \
* -
Dsitearch=/usr/lib/perl5//site_perl \
* -
Dvendorlib=/usr/share/perl5/vendor_perl \
* -
Dvendorarch=/usr/lib/perl5//vendor_perl \
-
Dman1dir=/usr/share/man/man1 \
-Dman3dir=/usr/share/man/man3 \
-
Dpager="/usr/bin/less -isR" \
-Duseshrplib \
-
Dusethreads
assuming that we have in packages.ent:
This will produce a directory structure:
/usr
/lib
/perl5
/5.30
/core_perl
/...
/site_perl
/...
where modules are installed under /usr/lib/perl5/5.30/site_perl/ . In
this case, overwriting the installed perl with a newer one has no
effect on the installed modules unless minor or even major version of
perl changes.
A note to "make install" might be required as perl refuses to
overwrite an installation in case of an version mismatch (which makes
sense in case of incompatible version, maybe when minor or major
version changes). To overcome this, a
mv /usr/bin/perl{,.old}
can be executed before doing the install.
As far as i have seen, there is no change required for BLFS except one
textual adjustment in the "Perl Modules" page.
All comments, suggestions, tomatos and eggs are welcome!
Is there something i have completely overseen?
--
Thomas
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] gcc-10 and stack protector in kernel
Am Montag, den 11.05.2020, 09:50 +0200 schrieb Pierre Labastie via
lfs-dev:
> Sorry if this has already been reported. With gcc 10 and kernel 5.6.11,
> I get:
> Kernel panic - not syncing: stack-protector: Kernel stack is corrupted
> in: start_secondary+0x169/0x170
>
> at early boot.
> this has been reported upstream [1], who made a complicated patch,
> mainly consisting of comments. It seems it occurs only when
> CONFIG_STACKPROTECTOR_STRONG=y. I do not know which kernel will have
> it. 5.6.12 doesn't.
>
> Two possibilities: remove the STACK_PROTECTOR_STRONG config, or apply
> this sed:
>
> sed -e '/cpu_startup/a asm("");' -i arch/x86/kernel/smpboot.c
>
> which does not fix xen kernel, but does everything else the patch does.
>
> Pierre
>
> [1] end of a long thread on lkml:
> https://lore.kernel.org/lkml/158798746828.28353.6010675315553653459.tip-bot2@tip-bot2/
>
Sorry for not responding in time.
I just compiled linux-5.6.13 first without the modifications and i
failed to boot with exactly the same kernel-panic.
According to a patch which can be found on lkml, i modified the
sources by applying
diff -Naur linux-5.6.13.orig/arch/x86/kernel/smpboot.c linux-
5.6.13/arch/x86/kernel/smpboot.c
--- linux-5.6.13.orig/arch/x86/kernel/smpboot.c 2020-03-30
00:25:41.0 +0200
+++ linux-5.6.13/arch/x86/kernel/smpboot.c 2020-05-19
14:00:42.250125049 +0200
@@ -262,6 +262,7 @@
wmb();
cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
+ asm(""); // disable tail-call optimization
}
/**
diff -Naur linux-5.6.13.orig/arch/x86/xen/smp_pv.c linux-
5.6.13/arch/x86/xen/smp_pv.c
--- linux-5.6.13.orig/arch/x86/xen/smp_pv.c 2020-03-30
00:25:41.0 +0200
+++ linux-5.6.13/arch/x86/xen/smp_pv.c 2020-05-19 14:01:41.717566594
+0200
@@ -92,6 +92,7 @@
cpu_bringup();
boot_init_stack_canary();
cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
+ asm(""); // disable tail-call optimization
}
void xen_smp_intr_free_pv(unsigned int cpu)
And with this, machine boots. Btw, i have
CONFIG_STACKPROTECTOR_STRONG=y
I'd vote for applying the patch (or a sed) rather than unsetting
CONFIG_STACKPROTECTOR_STRONG as at least the name of this option
sounds like it has to do with security. Switching off security i think
is the second best. But i also have to admit that i haven't read the
documentation about those options, yet.
--
Thomas
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] proposal: some improvements to LFS book
Am Montag, den 11.05.2020, 19:51 +0800 schrieb Xi Ruoyao via lfs-dev:
> I just redone LFS build for GCC-10.1.0. I proposed several improvements
> during
> the process:
>
> At first, some changes suggested by Firas:
>
> 1. Remove bzip2 in Chap. 5. No other changes needed.
>
> 2. Remove ncurses in Chap. 5. Move Chap. 6 readline after ncurses to satisify
> it.
> Notes:
> (1) Chap. 5 Python 3 can be built w/o ncurses, just lacking one module we
> don't
> need.
> (2) We moved readline before bc to satisify GNU bc, but now Gavin's bc doesn't
> need readline.
> (3) It slightly reduces the functionality of Chap. 5 bash. Long command lines
> won't be wrapped automatically anymore.
Just had the joy to do a bit manually on such kind of cmdline (help
testing Pierres branch) and there we ran into this. Really no fun.
Reme
mber that we always tell the users to do everything manually (at least
for the first time) and do not script because scripts add another
layer of errors.
So we "force" them to use such kind of command line - I'd say second-
best.
>
> 3. Remove flex in Chap. 5. Move Chap. 6 flex before Binutils so `ranlib` and
> `ar` can link to libfl.so. It seems bison test suite does not depends on flex
> any more.
>
> However Firas' other suggestions are proved to be impossible. Glibc requires
> bison, gzip, gettext, perl, texinfo, python, and xz (to be untarred) so all of
> them need to stay in Chap. 5. Util-linux can't be removed from Chap. 5 due to
> its circular dependency with systemd/eudev.
>
> And:
>
> 4. Move Chap. 6 zstd before GCC, so GCC can link to libzstd.so and use zstd to
> compress LTO stream.
>
> 5. Remove PKG_CONFIG_PATH=/tools/lib/pkgconfig in Chap. 6 kbd. It seems
> unneeded now.
>
> 6. Remove PERL5LIB=$PWD/tests/ in Chap. 6 make. It is unneeded now.
>
> 7. Add:
>
> mkdir /tools/lib/locale
> localedef -i POSIX -f UTF-8 C.UTF-8 2> /dev/null || true
>
> into Chap. 5 Glibc. It will satifisy Chap. 6 man-db test.
>
> 8. Remove libctf{,-nobfd}.a (along with libbfd.a and libopcodes.a) in
> "Cleaning
> up" section.
>
> Are they OK to be commited into trunk?
> --
> Xi Ruoyao
> School of Aerospace Science and Technology, Xidian University
>
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Need update to Fop-2.4 instructions
Am Samstag, den 11.04.2020, 11:53 -0500 schrieb Timothy Russo via lfs- dev: > I'm building a current LFS/BLFS system and while loading Fop-2.4 this > morning, the required download links for PDFBox and PDFBox Fonts need to be > updated to pdfbox/2.0.19. It looks like this was updated Feb 20th. > > Also, just a side question, has anyone done a LFS/BLFS Systemd-multilib patch? > I followed Thomas' updated LFS multilib but I wanted systemd so I finangled > my way through combining the systemd build and his multilib build to get LFS > complete. I just wasn't sure how much of BLFS would also need to be compiled > multilib for it all to work together nicely. you don't *need* to build any lib32-stuff to run the system. But if you have built ML in LFS, then you *could*. Which packages you might need in 32bit depends on what you're going to do with your system or what you need on your system. I've a printer driver which is only available in 32bit binary (which was the trigger to setup LFS-multilib) for which i need at least lib32-nettle and lib32-cups. VirtualBox (using the LFS system as host) needs ML-support internally. So there's no clear direction pointing to "you need X and Y" it depends on what you need. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib patch
Am Dienstag, den 24.03.2020, 12:44 -0500 schrieb Timothy Russo via lfs-dev: > Whatever happened to the multilib patch? I was following the thread back in > August 2018: > On 08/25/2018 12:13 AM, DJ Lucas wrote: > > > One more thing, need to add lib32 paths to remove-la-files.sh. I, thus > > far, have not messed with lib32x. I used a separate path for files in > > /usr/lib32. Same for /usr/lib32/pkgconfig and /usr/local/lib32/pkgconfig. > > > > On second thought, there is no purpose for the pc files in > /usr/lib32/pkgconfig, should just remove the directory if it exists. > Regardless of the libdir value in the pc file, the libraries themselves > will always be in the library search path because of our change to > /etc/ld.so.conf. > > --DJ > > and then it seemed to die. > I've found this: http://www.linuxfromscratch.org/~dj/lfs-systemd-multilib/ > from Nov 2018. > However, I'd love to help/test/edit an updated multilib patch to work against > the current 9.1 version of LFS/BLFS. > I was able to get my printer to work with multilib using these outdated > references, but I was only able to get steam to function with a flatpak. > If DJ or Thomas would like to revisit the multilib patch or > lfs-systemd-multilib version of the book, I'd love to help. Hi Tim, ML is still maintained - well, basically its a periodical merge of the trunk to the branch and subsequently fixing clashes ;-) You can find it at http://www.linuxfromscratch.org/~thomas/multilib/index.html and the sources are in a branch named 'multilib' in SVN. Feel free to post patches/ideas/remarks! -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Inaccuracy in chroot page
Am Samstag, den 14.03.2020, 18:11 +0100 schrieb Pierre Labastie via lfs-dev: > Le 14/03/2020 à 17:36, Bruce Dubbs via lfs-dev a écrit : > > On 3/14/20 10:55 AM, Pierre Labastie via lfs-dev wrote: > > > Le 14/03/2020 à 16:00, Bruce Dubbs via lfs-dev a écrit : > > > > On 3/14/20 3:41 AM, Pierre Labastie via lfs-dev wrote: > > > > > In "6.4 Entering the Chroot Environment", we have: > > > > > > > > > > From this point on, there is no need to use the LFS variable > > > > > anymore, > > > > > because > > > > > all work will be restricted to the LFS file system. This is because > > > > > the Bash > > > > > shell is told that $LFS is now the root (/) directory. > > > > > > > > > > But it is not true that the bash shell is told anything: the _kernel_ > > > > > is told > > > > > that $LFS is now the root (/) directory for all the processes > > > > > launched by the > > > > > first one (that is, here, "env", which itself launches "bash", which > > > > > will > > > > > launch all the others). I am not sure how to phrase this: something > > > > > like: > > > > > - > > > > > ... system. This is because the kernel is told that $LFS is now the > > > > > root (/) > > > > > directory for all the programs run from the current Bash shell. > > > > > - > > > > > But I'm sure native English writers can find something better (without > > > > > excluding non native of course :) > > > > > > > > I think I disagree with your premise. bash IS told where the root > > > > directory > > > > is, but there is some interaction with the kernel. > > > > > > > > When I enter chroot, env no longer exists. It does an 'exec' and > > > > replaces > > > > itself with bash. I took a look at /proc/ for that instance of > > > > bash and > > > > in that directory is the pseudo file 'mounts'. That tells me: > > > > > > > > /dev/sda6 / ext4 rw,noatime 0 0 > > > > > > > > which is my /mnt/lfs directory on the host. My interpretation is that > > > > this is > > > > a configuration for bash. When doing 'cd /', the kernel looks at this > > > > configuration for the bash instance and uses that to determine what disk > > > > partition (it could be a directory) to use for the head of an absolute > > > > path. > > > > > > > > In my opinion what we have now is correct. > > > > > > > > > > Thinking a little more about this, what I mean is the following: bash is > > > not > > > "told" anything, and does not "know" that "/" is $LFS: bash may ask the > > > kernel > > > to open(2) (or stat(2), or other basic calls) a file by passing the > > > filename > > > to the kernel, say, /a/file/name, and it is the kernel which resolves that > > > filename to $LFS/a/file/name, not bash itself. > > > > I'm OK with: > > > > This is because the Bash shell is set up so that $LFS is now the root (/) > > directory. > > > > That is: sed /told/set up so/ > > > > I just feel like I cannot explain. Bash is _unchanged_: it is the _kernel_, > which is set up so that $LFS is the new root for the process where bash (or > anything fork(2)ed from bash) is running. I agree, i think bash not even know that its running in chroot. > Anyway, nobody has complained for > years, let's not change anything. It does not prevent the build to work. also true > Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Building Glibc without the Info pages?
Am Dienstag, den 10.03.2020, 17:19 +0800 schrieb Kevin Buckley via lfs-dev: > As I usually build against Thomas Trepl's Multilib book, I've realised > that I end up building the Glibc Info pages SIX times, three in Chapter 5 > and three in Chapter 6. Thats for sure kinda redundant. It might be caused by building glibc for m64, m32 and mx32 in each of chapter 5 and 6, sums up to 6 times. Ususally for a normal build using the "standard" book, only one time is wasted (the one in chapter 5), so much efforts has not been taken do avoid redundant builds. > I've been looking at the Glibc Makefile hierarchy but couldn't see an > obvious place at which to prevent the Info pages being built. > > It looks like there's a subdir build on the "manual" subdirectory > during the "make install" but I'm having a hard time unravelling > the actual target and/or rule to avoid. > > Anyone on here got any "previous" in this area? Not yet, but this might be an interesting add-on in ML-book... -- Thomas btw, thanks for using the ML-book and especially providing hints, bugfixes and other tweaks! -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] 20 years LFS
Hi all,
well, its not really the first time i took a look to the {,B}LFS-book
this year ;-) but today I realized what is written in the Copyright
statement:
> Copyright © 1999-2019 Gerard Beekmans
This is now 20 years LFS!
Thanks to Gerard for the project, all the editors came and went away
and of course the current leaders and editors! Its been a great time
so far, wonder where LFS will take us in the future.
Ok, its about three years to go for celebrating the 20th anniversary
of version 1.0 (tarball's timestamp is 2002-11-04) but LFS as such was
born already...
--
Thomas
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Searching for a chapter on multilib
Am Donnerstag, den 11.07.2019, 10:29 -0400 schrieb Lewis Pike via lfs- dev: > Hi all, > > Last year, I went through the process of adding multilib support to my > existing 64-bit LFS system. I had come across what appeared to be a > fork of the book at > http://www.linuxfromscratch.org/~dj/history/lfs-systemd-multilib/ > which contained an additional chapter (Chapter 10) addressing this > very topic. > > Sadly, the above link is now dead and the notes I had taken at the > time aren't sufficient to reproduce my prior build. > > Might anyone have a copy of this fork or know where it can be found? > > .lewis Hi Lewis, thanks for showing interests in doing multilib stuff. DJ's work you refered to was a big big help to setup the ML-branch you can find at http://www.linuxfromscratch.org/~thomas/multilib/index.html - i think it has been mentioned allready in this thread. Without thinking about much in detail, adding ML support to an existing non-ML system should not be more difficult than seting up a fresh one. I think you'll just have to redo the core utils to be ML enabled, than redo the other libs. There are several libs in the ML-bool which are built in 32bit mode too even they are not really required to run the (LFS) system. But when going on to more sofisticated packages it will turn out that they will need them. Thats the reason why those libraries are built in LFS book, its just to provide ML support for doing BLFS. The essence of ML is in binutils/gcc/glibc - this is where ML "lives". -- Thomas Btw, after being away for vacation, i just merged the latest changes to the ML-book, its now on SVN-20190721. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Things could get much worse for bzip2
Am Donnerstag, den 27.06.2019, 05:24 -0400 schrieb Marty Jack via lfs- dev: > Reading the new homepage, it seems this is the gentleman who rewrote librsvg > in Rust and plans to do the same for bzip2. If he cannot be dissuaded, this > will have a disastrous effect on Chapter 5. Right, unfortunatly. I'm still using the last version of non-rust-librsvg. Up to now, it seems to work fine. Of course, bugfixes are not there. (in my undergraduated mind i never understood whats so cool in rust which justifies that monster of compiler infrastructure, and in this case, such a monster building a relativly small tool) -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Upgrades in LFS
Hi all, i'm just in the process of running thru a modified book including (most of) the version upgrades (linux, e2fsprogs, perl, eudev, bison, openssl) to see what happens using them. I just saw that they has been commited in the minute... I was to slow in reporting my findings (while compilation and checks are currently still running), but it seems so that the sed in perl regarding the gcc-versions is no longer required. When upgrading LFS packages, i think we should do a quick check on seds or patches created by our own whether they are still required. Thats also true for e2fsprogs-1.45.2 were a fix has been included due to my report of that strange install behavior in case /etc/cron.d does not exist. The option --with-crond-dir=no is no longer required for LFS (while does not harm anyway) as e2fsprogs now does the checking right. I'm also testing the new bc (#4436) which seems to be actively maintained and is now on v2.0.2. Looks like it works well - at least i didn't notice any failures trackable down to bc. Btw, we have statements in gcc echoing a #define STANDARD_STARTFILE_PREFIX_1 etc. to some files. Couldn't that be simplified if we change gcc/gcc.c (the STANDARD_STARTFILE_PREFIXes are defined there)? I'm going to test that when build is finished... -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] e2fsprogs 1.45.1 + patch
Am Montag, den 13.05.2019, 10:31 +0200 schrieb thomas via lfs-dev:
> Just a few hours ago they released 1.45.1 of e2fsprogs.
> Unfortunatly, nothing changed in the crond_dir case.
>
> Anyway, I've reported that to Ted - lets see if he (or others) will have
> a lok at it.
>
> --
> Thomas
Got following answer+fix from Ted:
>>>
On Mon, May 13, 2019 at 11:08:44AM +0200, thomas wrote:
> Hi Ted,
>
> if your time allows, could you have a quick look to following issue?
>
> What is it about
>
>
> When installing on a (non-systemd-)machine where no cron is
installed (yet),
> the installation of e2scrub_all does some strange things. It looks
to me
> that the issue is not related to systemd vs. sysv.
Thanks for your bug report! I beleive this patch should fix things;
can you test and confirm?
- Ted
commit a9cf13748946ce9ceb56f962fc22b965048d2cef
Author: Theodore Ts'o
Date: Wed May 22 13:03:38 2019 -0400
configure: fix test where cron is not installed on a non-systemd
system
Reported-by: tho...@linuxfromscratch.org
Signed-off-by: Theodore Ts'o
diff --git a/configure b/configure
index 205b2d6dc..065bff761 100755
--- a/configure
+++ b/configure
@@ -13150,7 +13150,8 @@ fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
$ac_cv_lib_blkid_blkid_probe_get_topology" >&5
$as_echo "$ac_cv_lib_blkid_blkid_probe_get_topology" >&6; }
if test "x$ac_cv_lib_blkid_blkid_probe_get_topology" = xyes; then :
- $as_echo "#define HAVE_BLKID_PROBE_GET_TOPOLOGY 1" >>confdefs.h
+
+$as_echo "#define HAVE_BLKID_PROBE_GET_TOPOLOGY 1" >>confdefs.h
fi
@@ -13191,7 +13192,8 @@ fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
$ac_cv_lib_blkid_blkid_probe_enable_partitions" >&5
$as_echo "$ac_cv_lib_blkid_blkid_probe_enable_partitions" >&6; }
if test "x$ac_cv_lib_blkid_blkid_probe_enable_partitions" = xyes;
then :
- $as_echo "#define HAVE_BLKID_PROBE_ENABLE_PARTITIONS 1"
>>confdefs.h
+
+$as_echo "#define HAVE_BLKID_PROBE_ENABLE_PARTITIONS 1" >>confdefs.h
fi
@@ -14511,6 +14513,8 @@ if test "x${with_crond_dir}" != "xno"; then :
if test -d "/etc/cron.d"; then :
with_crond_dir="/etc/cron.d"
+else
+ have_crond="no"; with_crond_dir=""
fi
fi
diff --git a/configure.ac b/configure.ac
index 3b86c1a14..cf03444d8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1674,7 +1674,8 @@ AS_IF([test "x${with_crond_dir}" != "xno"],
AS_IF([test "x${with_crond_dir}" = "xyes"],
[
AS_IF([test -d "/etc/cron.d"],
- [with_crond_dir="/etc/cron.d"])
+ [with_crond_dir="/etc/cron.d"],
+ [have_crond="no"; with_crond_dir=""])
])
AC_MSG_CHECKING([for system crontab dir])
crond_dir="${with_crond_dir}"
<<<
No need to specify the --with-crond-dir=no option at configure command
anylonger (and no 'yes'-directory). Find the (reformatted) patch
attached.
--
Thomas
diff -Naur e2fsprogs-1.45.1.orig/configure e2fsprogs-1.45.1/configure
--- e2fsprogs-1.45.1.orig/configure 2019-05-13 03:23:53.0 +0200
+++ e2fsprogs-1.45.1/configure 2019-05-22 19:41:28.234071070 +0200
@@ -14511,6 +14511,8 @@
if test -d "/etc/cron.d"; then :
with_crond_dir="/etc/cron.d"
+else
+ have_crond="no"; with_crond_dir=""
fi
fi
diff -Naur e2fsprogs-1.45.1.orig/configure.ac e2fsprogs-1.45.1/configure.ac
--- e2fsprogs-1.45.1.orig/configure.ac 2019-05-13 03:23:53.0 +0200
+++ e2fsprogs-1.45.1/configure.ac 2019-05-22 19:42:34.413062225 +0200
@@ -1674,7 +1674,8 @@
AS_IF([test "x${with_crond_dir}" = "xyes"],
[
AS_IF([test -d "/etc/cron.d"],
- [with_crond_dir="/etc/cron.d"])
+ [with_crond_dir="/etc/cron.d"],
+ [have_crond="no"; with_crond_dir=""])
])
AC_MSG_CHECKING([for system crontab dir])
crond_dir="${with_crond_dir}"
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] e2fsprogs + crond
Am Montag, den 13.05.2019, 00:47 +0100 schrieb Ken Moffat via lfs-dev: > On Sun, May 12, 2019 at 10:25:34PM +0200, Thomas Trepl via lfs-dev wrote: > > Hi all, > > > > i just started a build of a new system. To my surprise, it failed in > > chap6 at e2fsprogs where it never stopped before. > > The reason for stopping is > > > > > > ake[1]: Leaving directory '/autolfs/sources/e2fsprogs-1.45.0/build/po' > > making install in scrub > > make[1]: Entering directory '/autolfs/sources/e2fsprogs- > > 1.45.0/build/scrub' > > MKDIR_P /usr/lib/e2fsprogs > > MKDIR_P yes > > INSTALL yes/e2scrub_all > > /usr/bin/install: cannot create regular file 'yes/e2scrub_all': No > > such file or directory > > make[1]: *** [Makefile:447: install-crond] Error 1 > > make[1]: *** Waiting for unfinished jobs > > make[1]: Leaving directory '/autolfs/sources/e2fsprogs- > > 1.45.0/build/scrub' > > make: *** [Makefile:434: install-progs-recursive] Error 1 > > make: *** Waiting for unfinished jobs > > make[1]: Leaving directory '/autolfs/sources/e2fsprogs- > > 1.45.0/build/lib/et' > > making install-shlibs in lib/ss > > make[1]: Entering directory '/autolfs/sources/e2fsprogs- > > 1.45.0/build/lib/ss' > > > > > > A look to the build/Makefile showed > > > > > > HAVE_UDEV = no > > UDEV_RULES_DIR = > > HAVE_CROND = yes > > CROND_DIR = yes > > HAVE_SYSTEMD = no > > SYSTEMD_SYSTEM_UNIT_DIR = > > > > > > Note the setting of CROND_DIR. I checked the configure script and > > found in line ~14500 a check on option $with_crond_dir=[yes,no]. If > > not set, yes is assumed. Later on, in case $with_crond_dir == yes, the > > test if /etc/cron.d exists and set with_crond_dir to /etc/cron.d if > > the directory is there. It remains "yes" if that directory does not > > exist. I assume that is the reason why CROND_DIR set to "yes" in the > > Makefile. > > > > What i really do not understand is why that happens now and never > > before? We have e2fsprogs-1.45.0 a good amount of time in the book, > > there is nothing new but if my reading of the configure script is > > correct, there is a fulminant logical error in it. Wonder why that > > never came up before. > > > > What do you think, am i right in interpreting the section in the > > configure script that there is a logical bug in it? If so, i do not > > get it why it comes up now and not at all the previous builds too... > > > > Btw, i specified --with-crond-dir=no and compilation/installation of > > e2fsprogs went fine. > > > I've just looked at my build from a couple of days ago - > > checking for udev... no > checking for udev rules dir... no > checking for system crontab dir... yes > checking for systemd... no > > make[2]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub' > ../util/subst -t -f ../util/subst.conf ../../scrub/e2scrub_all.cron.in > e2scrub_all.cron > make[2]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub' > make[2]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub' > ../util/subst -t -f ../util/subst.conf ../../scrub/e2scrub_all_cron.in > e2scrub_all_cron > chmod a+x e2scrub_all_cron > make[2]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub' > > make[1]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub' > MKDIR_P yes > make[1]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub' > make[1]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub' > MKDIR_P /usr/lib/e2fsprogs > make[1]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub' > make[1]: Entering directory '/building/e2fsprogs-1.45.0/build/scrub' > INSTALL yes/e2scrub_all > make[1]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub' > make[1]: Entering directory '/building/e2fsprog > INSTALL /usr/lib/e2fsprogs/e2scrub_all_cron > make[1]: Leaving directory '/building/e2fsprogs-1.45.0/build/scrub' > > From that, I would expect to have a directory called 'yes'. > Fortunately, it was not *that* broken. Sure? It should be in ~/e2fsprogs-1.45.0/build/scrub/. I just rerun $ sudo make install and e voila, here in ~/e2fsprogs-1.45.0/build it is: $ dir scrub/ insgesamt 68 drwxr-xr-x 3 lfs users 4096 13. Mai 08:21 . drwxr-xr-x 15 lfs users 4096 13. Mai 07:56 .. -r-xr-xr-x 1 lfs users 6738 13. Mai 07:57 e2scrub -r--r--r-- 1 lfs users 1751 13. Mai 07:57 e2scrub.8 -r-xr-xr-x 1 lfs users 4107 13. Mai 07:57 e2scrub_all -r--r--r-- 1 lfs users 1068 13. Mai 07:57 e2scrub_all.8 -r--r--r-- 1 lfs
Re: [lfs-dev] e2fsprogs + crond
Am Sonntag, den 12.05.2019, 17:45 -0500 schrieb Bruce Dubbs via lfs- dev: > On 5/12/19 3:25 PM, Thomas Trepl via lfs-dev wrote: > > Hi all, > > > > i just started a build of a new system. To my surprise, it failed in > > chap6 at e2fsprogs where it never stopped before. > > The reason for stopping is > > > > > > make[1]: Entering directory '/autolfs/sources/e2fsprogs- > > 1.45.0/build/scrub' > > MKDIR_P /usr/lib/e2fsprogs > > MKDIR_P yes > > INSTALL yes/e2scrub_all > > /usr/bin/install: cannot create regular file 'yes/e2scrub_all': No > > ... > > My logs show: > > > making install in scrub > make[2]: Entering directory '/sources/e2fsprogs-1.45.0/build/scrub' > MKDIR_P yes > MKDIR_P /usr/lib/e2fsprogs > INSTALL yes/e2scrub_all > INSTALL /usr/lib/e2fsprogs/e2scrub_all_cron > MKDIR_P /sbin /usr/share/man/man8 /etc > SYMLINK /usr/lib/libe2p.so > INSTALL /sbin/e2scrub > INSTALL /sbin/e2scrub_all > INSTALL_DATA /usr/share/man/man8/e2scrub.8 > INSTALL_DATA /usr/share/man/man8/e2scrub_all.8 > INSTALL_DATA /etc/e2scrub.conf > make[2]: Leaving directory '/sources/e2fsprogs-1.45.0/build/scrub' There is that "MKDIR_P yes" too and later, an install to that yes- directory happens. I'm not sure why it breaks here, but not at your system. Anyway, isn't that 'yes' fundamentaly wrong? > > Are you running make install at -jx where x > 1 ? I'll run tests about this later without -j5 (which is set by default here). A quick redo of install using DESTDIR (and without MAKEFLAGS) shows $ sudo make install Q= DESTDIR=/tmp/e2fs ... make[1]: Verzeichnis „/home/lfs/e2fsprogs-1.45.0/build/scrub“ wird betreten for i in e2scrub.rules; do \ echo " INSTALL /lib/udev/rules.d/$i"; \ /usr/bin/install -c -m 644 $i /tmp/e2fs/lib/udev/rules.d/96- $i; \ done MKDIR_P yes /bin/mkdir -p /tmp/e2fsyes MKDIR_P /usr/lib/e2fsprogs /bin/mkdir -p /tmp/e2fs/usr/lib/e2fsprogs MKDIR_P /lib/udev/rules.d /bin/mkdir -p /tmp/e2fs/lib/udev/rules.d if test -n "e2scrub_all.cron" ; then \ echo " INSTALL yes/e2scrub_all" ; \ /usr/bin/install -c -m 644 e2scrub_all.cron /tmp/e2fsyes/e2scrub_all ; \ fi for i in e2scrub_all_cron; do \ echo " INSTALL /usr/lib/e2fsprogs/$i"; \ /usr/bin/install -c $i /tmp/e2fs/usr/lib/e2fsprogs/$i; \ done INSTALL /lib/udev/rules.d/e2scrub.rules INSTALL yes/e2scrub_all INSTALL /usr/lib/e2fsprogs/e2scrub_all_cron MKDIR_P /sbin /usr/share/man/man8 /etc /bin/mkdir -p /tmp/e2fs/sbin \ /tmp/e2fs/usr/share/man/man8 /tmp/e2fs/etc for i in e2scrub e2scrub_all; do \ echo " INSTALL /sbin/$i"; \ /usr/bin/install -c $i /tmp/e2fs/sbin/$i; \ done INSTALL /sbin/e2scrub INSTALL /sbin/e2scrub_all for i in e2scrub.8 e2scrub_all.8; do \ for j in gz bz2 bz Z; do \ /bin/rm -f /tmp/e2fs/usr/share/man/man8/$i.$j; \ done; \ echo " INSTALL_DATA /usr/share/man/man8/$i"; \ /usr/bin/install -c -m 644 $i /tmp/e2fs/usr/share/man/man8/$i; \ done INSTALL_DATA /usr/share/man/man8/e2scrub.8 INSTALL_DATA /usr/share/man/man8/e2scrub_all.8 for i in e2scrub.conf; do \ echo " INSTALL_DATA /etc/$i"; \ /usr/bin/install -c -m 644 $i /tmp/e2fs/etc/$i; \ done INSTALL_DATA /etc/e2scrub.conf make[1]: Verzeichnis „/home/lfs/e2fsprogs-1.45.0/build/scrub“ wird verlassen ... $ ls -la /tmp ... drwxr-xr-x 7 root root 4096 13. Mai 08:00 e2fs drwxr-xr-x 2 root root 4096 13. Mai 08:00 e2fsyes ... Strange, isn't it? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] e2fsprogs + crond
Hi all, i just started a build of a new system. To my surprise, it failed in chap6 at e2fsprogs where it never stopped before. The reason for stopping is ake[1]: Leaving directory '/autolfs/sources/e2fsprogs-1.45.0/build/po' making install in scrub make[1]: Entering directory '/autolfs/sources/e2fsprogs- 1.45.0/build/scrub' MKDIR_P /usr/lib/e2fsprogs MKDIR_P yes INSTALL yes/e2scrub_all /usr/bin/install: cannot create regular file 'yes/e2scrub_all': No such file or directory make[1]: *** [Makefile:447: install-crond] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: Leaving directory '/autolfs/sources/e2fsprogs- 1.45.0/build/scrub' make: *** [Makefile:434: install-progs-recursive] Error 1 make: *** Waiting for unfinished jobs make[1]: Leaving directory '/autolfs/sources/e2fsprogs- 1.45.0/build/lib/et' making install-shlibs in lib/ss make[1]: Entering directory '/autolfs/sources/e2fsprogs- 1.45.0/build/lib/ss' A look to the build/Makefile showed HAVE_UDEV = no UDEV_RULES_DIR = HAVE_CROND = yes CROND_DIR = yes HAVE_SYSTEMD = no SYSTEMD_SYSTEM_UNIT_DIR = Note the setting of CROND_DIR. I checked the configure script and found in line ~14500 a check on option $with_crond_dir=[yes,no]. If not set, yes is assumed. Later on, in case $with_crond_dir == yes, the test if /etc/cron.d exists and set with_crond_dir to /etc/cron.d if the directory is there. It remains "yes" if that directory does not exist. I assume that is the reason why CROND_DIR set to "yes" in the Makefile. What i really do not understand is why that happens now and never before? We have e2fsprogs-1.45.0 a good amount of time in the book, there is nothing new but if my reading of the configure script is correct, there is a fulminant logical error in it. Wonder why that never came up before. What do you think, am i right in interpreting the section in the configure script that there is a logical bug in it? If so, i do not get it why it comes up now and not at all the previous builds too... Btw, i specified --with-crond-dir=no and compilation/installation of e2fsprogs went fine. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib LFS and other variants
Am Donnerstag, den 02.05.2019, 21:23 +0100 schrieb Ken Moffat via lfs- dev: > On Thu, May 02, 2019 at 09:39:44PM +0200, Thomas Trepl via lfs-dev wrote: > > Regarding pkgmngt, i started a project for my own to see how > > pkgmngt may work. There is no heavy development on > > https://www.belfs.org since its a one-man- and spare-time show but it > > works for me so far and a new rework will come up these days. > > Certificate seems to be only valid for ispgateway (or perhaps only > for its webserver) - firefox dislikes it because it is not valid for > www.belfs.org, reporting "The certificate is only valid for ." > > Looking at it 'Could not verify this certificate because the issuer > is unknown.' > > Error code: MOZILLA_PK1X_ERROR_SELF_SIGNED_CERT. > Ouch ... fixed. I redirected from http to https first and than to https at io.ax.lt. There is a valid cert. The first redirect was no good and now it goes directly to io.ax.lt regardless if you request http or https. Thanks! -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib LFS and other variants
Am Freitag, den 03.05.2019, 01:58 +1000 schrieb James B via lfs-dev: > Hi guys, > > I've been lurking in this mailing list for quite a while now and seen some > developments going on. > > Specifically, I have seen Thomas' multilib work being discussed and I think > Thomas recently put his work into somewhere in LFS website. I've also seen > comments about "LFS with package management" but I've never actually seen the > book. > > These are two that I'm aware, and there may be others. However, I want to > highlight that googling "LFS multilib" doesn't bring me anywhere, > specifically it doesn't bring up Thomas work. Could it be because there is no > link from LFS main website to his? If I want to access Thomas website I need > to know the exact URL: http://www.linuxfromscratch.org/~thomas/multilib/ Yes, thats the link currently shows the "ML-enabled" book. It may be a bit beind the 'real' LFS book because i have to merge trunk from time to time into the ML-branch. Thats currently manual work and i do not believe that automated merge+commit will work stable. I'm really happy and feel honored (hope that its ok since its translated word by word from german "ich fühle mich geehrt") that my - and others! - work is somehow recognized. I assume that your interest in ML does not come out of the blue. It would be interesting to know something about the reason why you are searching for ML stuff. The answer might help to optimize the ML stuff and even more, if you have trouble building the ML system or trouble while using it (e.g. missing core libraries and such). > My apology if this has already been done; but if it has not, may I suggest > that we put a link from somewhere in LFS website to these? I understand that > they aren't official LFS works or projects (not on the same level as BLFS, > CLFS or ALFS), so the links should be marked as such; nevertheless, they're > valuable reference in their own right. Making these variants accessible from > the main site would be helpful for others. Well, yes, some kind of ML-enabled BLFS will be the next step. On the way to get my printer driver (32bit from DELL) working, at least nettle has to be built with -m32 ... Regarding pkgmngt, i started a project for my own to see how pkgmngt may work. There is no heavy development on https://www.belfs.org since its a one-man- and spare-time show but it works for me so far and a new rework will come up these days. DJ has published some work on pacman for LFS. You may check https://github.com/djlucas/LFS-systemd-pacman for that. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gcc9 test log
Am Mittwoch, den 24.04.2019, 10:04 -0500 schrieb Bruce Dubbs via lfs- dev: > On 4/24/19 12:34 AM, Thomas Trepl via lfs-dev wrote: > > Am Mittwoch, den 24.04.2019, 00:21 -0500 schrieb Bruce Dubbs via lfs- > > dev: > > > On 4/24/19 12:05 AM, Thomas Trepl via lfs-dev wrote: > > > > Hi, > > > > > > > > just for interest/fun I build a "full featured" gcc-9 including ada > > > > and all other available frontends. Note that there is a new language > > > > frontend for 'D' :-) > > > > > > > > All in all, it does not look bad, what do you think? > > > > > > Yes, looks pretty good. How long did it take to doo all that? Build > > > and installed sizes? > > > > > > -- Bruce > > > > My scripts reported > > > > INFO : 00:17:41 +--- > > INFO : 00:17:41 | Module ... gcc9 > > INFO : 00:17:41 | Duration . 13855 seconds > > INFO : 00:17:41 | SBU .. 144.32 > > INFO : 00:17:41 | Build size ... 12.5 GB > > INFO : 00:17:41 | Test size + 1.1 GB > > INFO : 00:17:41 | Bin size . 3.8 GB > > INFO : 00:17:41 | Total size ... 17.4 GB > > INFO : 00:17:41 +--- > > > > so it last nearly 4 hours using 4 cores in a VM with 4GB RAM. The > > 'Total size' includes everything, source, binaries and logfiles and so > > on. > > Thanks a lot. When gcc9 gets released, these numbers can be listed for > informative purposes even though we will probably not recommend building > everything. > >-- Bruce Yes, its an rough estimate. The above numbers (the duration) includes the test run (make -k check). Without, duration went down to 7464sec (77.75 SBU). And all this*) numbers are for a multilib-enabled gcc (m32 as well as mx32). A native 32bit gcc (of course non-multilib) lasts 5744sec (59.83 SBU) to build without check, but also including all available languages. -- Thomas *) to the native speakers: is 'this numbers' here correct or should it read 'these numbers' ? -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gcc9 test log
Am Mittwoch, den 24.04.2019, 00:21 -0500 schrieb Bruce Dubbs via lfs- dev: > On 4/24/19 12:05 AM, Thomas Trepl via lfs-dev wrote: > > Hi, > > > > just for interest/fun I build a "full featured" gcc-9 including ada > > and all other available frontends. Note that there is a new language > > frontend for 'D' :-) > > > > All in all, it does not look bad, what do you think? > > Yes, looks pretty good. How long did it take to doo all that? Build > and installed sizes? > >-- Bruce My scripts reported INFO : 00:17:41 +--- INFO : 00:17:41 | Module ... gcc9 INFO : 00:17:41 | Duration . 13855 seconds INFO : 00:17:41 | SBU .. 144.32 INFO : 00:17:41 | Build size ... 12.5 GB INFO : 00:17:41 | Test size + 1.1 GB INFO : 00:17:41 | Bin size . 3.8 GB INFO : 00:17:41 | Total size ... 17.4 GB INFO : 00:17:41 +--- so it last nearly 4 hours using 4 cores in a VM with 4GB RAM. The 'Total size' includes everything, source, binaries and logfiles and so on. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] gcc9 test log
Hi, just for interest/fun I build a "full featured" gcc-9 including ada and all other available frontends. Note that there is a new language frontend for 'D' :-) All in all, it does not look bad, what do you think? -- Thomas cat <<'EOF' | LAST_UPDATED: Obtained from SVN: trunk revision 270485 === acats tests === === acats Summary === # of expected passes2320 # of unexpected failures0 Native configuration is x86_64-pc-linux-gnu === gcc tests === Running target unix FAIL: gcc.target/i386/pr57193.c scan-assembler-times movdqa 2 === gcc Summary === # of expected passes139578 # of unexpected failures1 # of expected failures 536 # of unsupported tests 2146 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/xgcc version 9.0.1 20190421 (experimental) (GCC) === gdc tests === Running target unix === gdc Summary === # of expected passes29394 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/gdc version 9.0.1 20190421 (experimental) (GCC) === gfortran tests === Running target unix === gfortran Summary === # of expected passes50213 # of expected failures 188 # of unsupported tests 94 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/gfortran version 9.0.1 20190421 (experimental) (GCC) === g++ tests === Running target unix === g++ Summary === # of expected passes134395 # of expected failures 528 # of unsupported tests 5871 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/xg++ version 9.0.1 20190421 (experimental) (GCC) === gnat tests === Running target unix === gnat Summary === # of expected passes2981 # of expected failures 23 # of unsupported tests 3 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/gnatmake version 9.0.1 20190421 (experimental) === go tests === Running target unix FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments === go Summary === # of expected passes7349 # of unexpected failures1 # of expected failures 1 # of untested testcases 6 # of unsupported tests 1 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/gccgo version 9.0.1 20190421 (experimental) (GCC) === obj-c++ tests === Running target unix === obj-c++ Summary === # of expected passes1458 # of expected failures 10 # of unsupported tests 77 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/xg++ version 9.0.1 20190421 (experimental) (GCC) === objc tests === Running target unix === objc Summary === # of expected passes2797 # of expected failures 6 # of unsupported tests 68 /home/lfs/tmp/gcc9/build/gcc-9-20190421/build/gcc/xgcc version 9.0.1 20190421 (experimental) (GCC) === gotools tests === === gotools Summary === # of expected passes419 # of untested testcases 190 === libatomic tests === Running target unix === libatomic Summary === # of expected passes54 === libffi tests === Running target unix === libffi Summary === # of expected passes2214 === libgo tests === Running target unix FAIL: runtime/pprof === libgo Summary for unix === # of expected passes183 # of unexpected failures1 Running target unix/-m32 === libgo Summary for unix/-m32 === # of expected passes184 Running target unix/-mx32 FAIL: runtime/pprof === libgo Summary for unix/-mx32 === # of expected passes183 # of unexpected failures1 === libgo Summary === # of expected passes550 # of unexpected failures2 === libgomp tests === Running target unix === libgomp Summary === # of expected passes6499 # of expected failures 4 # of unsupported tests 349 === libitm tests === Running target unix === libitm Summary === # of expected passes42 # of expected failures 3 # of unsupported tests 1 === libphobos tests === Running target unix === libphobos Summary === # of expected passes750 === libstdc++ tests === Running target unix FAIL: 22_locale/time_get/get_time/char/2.cc execution test FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution test FAIL:
Re: [lfs-dev] Our perl builds are not hardened
Am Dienstag, den 23.04.2019, 04:09 +0100 schrieb Ken Moffat via lfs- dev: > On Thu, Apr 18, 2019 at 10:59:04PM +0100, Ken Moffat wrote: > > 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 > > This still applies to 5.28.2. I guess that distros such as fedora > and Arch have not reported this upstream because they *always* force > their own CFLAGS which include a -DFORTIFY_SOURCE setting. > > ... Is there a reason why we won't add that sed to the book? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
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 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
Re: [lfs-dev] Patching LFS XML sources: SVN insight required
Am Sonntag, den 31.03.2019, 10:04 +0800 schrieb Kevin Buckley via lfs- dev: > Hi there, > > I'd be interested in some feedback, should anyone have a chance to > look at things, as to how best to leverage SVN to add "mutiple > rendering pathways", so let me expand on that. > > The build system for the vanilla LFS book already has the ability to > branch on SysV or SysD. > > Thomas's patch adds multilib capability to either of those pathways. > > I am looking to apply a "PkgUser" (the More Control hint) approach > on top of that. > > My local (file-backed) SVN repo contains a mix of direct PkgUser > modifications, along with things such as > > 2>&1 | tee ../make.out > > being added into (hopefully) all of the various make commands, so including > the "make check/test" and "make install" stuff. > > I also make a few changes to blocks so as to remove some > things from the output generated by the book's Makefile's dump-commands > target. As you surly have seen, the ML stuff is controlled via 'arch="multilib"' or 'arch="default"' profiling attributes in the books sources. Using them made it possible to switch on/off the ML modifications at rendering time by setting a parameter to 'make'. So if set to "default", the rendering output should be exactly the output you get when using the original book and not using ML at all. You may use such a profiling attribute for your modifications as well but unfortunatly, docbook in the used version has only a limited set of those attrs while its possible to introduce own ones. > > What's not been clear to me in trying to store changes within my local > SVN repo is how to seperate things out so that for example, i could > apply a "PkgUser" SVN diff to a vanilla LFS XML source tree if it > hadn't had Thomas's Multilib patch already applied. > > Another one along the same lines is the make redirection stuff that > I add into my own books. That is what kept me busy for a while to get things done like you described. Goal was to minimze the impact on the "infrastructure" of the book (modifying the Makefile etc), simply be as much "compatible" as possible. Even jhalfs (with a few modifications DJ made) runs on the ML-variant. Finally, I end up with: Create a local copy of the LFS repository (svn checkout). This repo can be updated simply via "svn up". Than, i created a copy of the book (directory BOOK) and made my modifications there. A diff between this directory and the original repo is what is known as the multilib- patch. Same procedure is made for the so-called "belfs extensions" which are modifications i like to have in the book but which are surly nothing to ever go to the original book. For example, in this variant i use the base kernel sources and a patch to get them uptodate (linux- 5.0.tar.xz + patch-5.0.4.xz) simply to save diskspace and download time... To keep things uptodate, i run a script which does: - diff the ML working dir and the upstream repo and store the patch in a temporary location - diff the BELFS working dir and the upstream repo and store the patch in a temporary location - update the upstream repository (never to that before the first two steps has been made) - duplicate the original sources into the ML working dir (via rsync -- delete) - apply the temp-patch to it - create the ML-patch (now this patch is against the most recent original sources) - duplicate the original sources into the BELFS working dir - apply the temp-patch to it - create the BELFS-patch - duplicate the original sources into the "merged" working dir - apply the BELFS-patch to it - apply the ML-patch to it - copy the BELFS- and the ML-patch to my website This process runs every day at 04:45. I use the interdiff utils to see whether there are differences between the previous and the newly created patches. If none, the new patches are thrown away. The description sounds a bit complicated but usually the process runs well, from time to time some .rej are created. That happens if there are modifications made in the original repo which are in conflict with my modifications. Then i have to fix that manually. I use the "merged" book for building my machines. Problem in this approach is that i cannot track my modifications in a SVN repository since the BELFS and the ML copies are simple file copies and are not under SVN control. The only history i have is that i keep the previously created patches. Next step will be to make a branch in the original repository for the ML part. > > Whilst that's not realy PkgUser specific, i could see that a standlone > SVN diff that applied just that might be useful to some folk, but again > it's not clear how to seperate things out when using SVN across the > two "regimes" I am adding stuff on top off, namely, the vanilla LFS and > the Multilib additional source. > > Any pointers/insight welcome. > Kevin > > PS > I have a rendering of my current book but am yet to stick it up on > the internet in case anyone wnats to take a look.:
Re: [lfs-dev] Multilib patch: ncurses 64-bit build wants to use /usr/lib32/pkgconfig
Am Samstag, den 23.03.2019, 17:39 +0800 schrieb Xi Ruoyao via lfs-dev:
> On Sat, 2019-03-23 at 16:48 +0800, Kevin Buckley via lfs-dev wrote:
*snip*
> > Anyroad, just came to do Chapter 6 ncurses after applying Thomas's patch
> > (note also I am doing a PkgUser build) and saw
> >
> > ** Configuration summary for NCURSES 6.1 20180127:
> >
> >extended funcs: yes
> >xterm terminfo: xterm-new
> >
> > bin directory: /usr/bin
> > lib directory: /usr/lib
> > include directory: /usr/include
> > man directory: /usr/share/man
> >terminfo directory: /usr/share/terminfo
> > pkg-config directory: /usr/lib32/pkgconfig
> >
> > and was surprised by the 32-bit Pkg-conf dir.
>
> *snip*
>
> > and so I thimk that the ncurses configure search "falls through" to
> > /usr/lib32
> > where it finds a directory named 'pkgconfig'
> >
> > The suggestion in the Ncurses build is that one can explicitly specify the
> > pkg-config directory by using a flag to ./configure.
>
> Yes. --with-pkg-config-libdir=/usr/lib64/pkgconfig would work.
>
> > Maybe that's something Thomas needs to add to his patch ?
Thanks Kevin and Xi, good spot!
Also the symlinks created later in that chapter for ncurses, form, panel and
menu are invalid
as ncursesw.pc does not exist in /usr/lib.
I think I have to add --with-pkg-config-libdir=/usr/lib/pkgconfig (not
.../lib64/...) since we do
not have a /usr/lib64 at all, /usr/lib is the 'default' for 64bit.
For the 32bit builds, this configure argument is set allready.
Alternativly, we could do a sed to remove lib32 in configure for the *64 case:
sed -e "/cf_path\/lib64/{n;d}" -i configure
but i think the configure argument is less intrusive and works well.
ML-patch is modified.
--
Thomas
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Multilib patch
Am Mittwoch, den 20.02.2019, 18:03 +0800 schrieb Kevin Buckley via lfs-dev: > Just wanted to tidy up the "loose end" here by saying that I did get an LFS > that was able to build Xen 4.10 going by using the Mutlilib patch against > LFS 8.3, and all this using a PkgUser approach. > > I have been tracking the changes I made in a local SVN, but am thinking > that I will wait for the 8.4 release before trying to feedback anything into > the > community. > > Thanks again for the MultiLib patch and feedback in this thread. > Kevin Cool stuff and thanks for the feedback - this one and the one may come! -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib patch
Am Mittwoch, den 20.02.2019, 18:03 +0800 schrieb Kevin Buckley via lfs-dev: > Just wanted to tidy up the "loose end" here by saying that I did get an LFS > that was able to build Xen 4.10 going by using the Mutlilib patch against > LFS 8.3, and all this using a PkgUser approach. > > I have been tracking the changes I made in a local SVN, but am thinking > that I will wait for the 8.4 release before trying to feedback anything into > the > community. > > Thanks again for the MultiLib patch and feedback in this thread. > Kevin Cool stuff and thanks for the feedback! -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Python 3.7.2 build errors using Glibc 2.29
Am Samstag, den 09.02.2019, 23:45 -0800 schrieb Brandon Murry via lfs- dev: > Hi, I hope this is the right place to put this. > I've been attempting to build Linux From Scratch from the development book > using Systemd. One of the big new changes is an early build of Python 3.7.2 > for the newest version of Glibc 2.29. I've tried this about 6 times trying > all different setups within the host environment. Compiling Python 3.7.2 > during chapter 5 produces a ton of "error: unknown type name" for standard C > libraries. > Python fails to build the majority of it's modules. When Glibc is rebuilt > during chapter 6, it fails due to missing Python modules. Haven't seen any > hints about this from LFS or on the net, so curious to see if I'm the only > one having this issue. > Thanks, > Brandon Whats your host system? (Distro, architecture etc.) Did you run the check script of chapter 2.2 ? Can you provide a snippet of the log where the errors are shown? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] perl install dirs
Hi all, here a question about install directories of perl. Currently, an installation of perl results in a structure like /usr +---> lib +---> perl5 +---> 5.28.0 +---> site_perl +---> 5.28.0 Installed perm modules seems to go mainly in /usr/lib/perl5/site_perl/5.28.0 and some files in /usr/lib/perl5/5.28.0. As we do not specify any pathes to the Configure command to perl, it seems that this is the default. The reason why i ask is what happens when perl gets upgraded (from 5.28.0 to 5.28.1). Looks like the result is a structure like /usr +---> lib +---> perl5 +---> 5.28.0 +---> 5.28.1 +---> site_perl +---> 5.28.0 +---> 5.28.1 Are the modules installed in the */5.28.0 directoies still available to perl or are they "lost" and need to be reinstalled in order to get placed into the */5.28.1 directories? Or does perl automatically recognize those multible directories? There are several options to the Configure script of perl (-Dprivlib -Darchlib -Dsitelib -Dvendorlib etc.) which seems to have influence on the final directory structure. Could the usage of those options ease the upgrade of perl (without having to rebuild the modules (if required))? (All those are dump questions as I'm really not an perl expert but i have the strong feeling that an in-place-upgrade of perl somehow breaks installed modules.) Whats your opinion? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib patch: Chapter 6 ISL/GCC instructions
Am Sonntag, den 13.01.2019, 12:48 +0800 schrieb Kevin Buckley via lfs- dev: > More of a heads up than somethng likley to affect most LFS builders, > but just to point out that one of the last commands in the GCC section > does the following > > = > Finally, move a misplaced file: > > mkdir -pv /usr/share/gdb/auto-load/usr/lib > mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib > == > > > however by the time you have reached that point in the > Multilib buid, there are actually two files matching > > /usr/lib/*gdb.py > > as the standalone ISL install has created > > /usr/lib/libisl.so.19.1.0-gdb.py > > to go along with GGC's > > /usr/lib/libstdc++.so.6.0.25-gdb.py > > > To my mind then, the directory creation should be really > being done as part of the ISL section, with the misplaced > file from that package being moved there then. > > > FYI: > > I only noticed this as I'm following a PkgUser build process, > and saw that the GCC PkgUser wasn't able to move the > file that had been created by the ISL PkgUser > > Hoping that's useful to someone, > Kevin I modified the patch to move those files at ISL and GCC separatly. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib patch
Am Sonntag, den 06.01.2019, 14:16 +0800 schrieb Kevin Buckley via lfs- dev: > A web search for my GCC-internal zlib config error > > configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES > > turned up, amongst others, these two, the first of which results from > an LFS build ! > > https://stackoverflow.com/questions/46487529/crosscompiling-gcc-link-tests-are-not-allowed-after-gcc-no-executables-when-che > > https://github.com/easybuilders/easybuild-easyconfigs/issues/3964 > > > The second of those suggests that it may be the lack of a "multilib capable" > toolchain ON THE HOST that is the issue for me? No, i've just tested building it from an LFS-8.2 without ML. That is what chapter 5 is for - make us (more or less) independent from host. > With that in mind, I'm coming back to my original remarks about rebuidling > in that: > > the way I last "upgraded" an x86_64 LFS to have multilib capibilty was by > following one of DJ's old books, wherein things were effectively done in > these stages: > > x86_64 host -> x86_64 LFS-tools > x86_64 LFS-tools -> x86_64 LFS > x86_64 LFS -> Multilib LFS-tools components > Multilib LFS-tools -> Multilib LFS components > > Indeed, after the Binutills pass1 now, the only file in /tools/bin are > > > x86_64-lfs-linux-gnu-addr2line x86_64-lfs-linux-gnu-nm > x86_64-lfs-linux-gnu-ar x86_64-lfs-linux-gnu-objcopy > x86_64-lfs-linux-gnu-as x86_64-lfs-linux-gnu-objdump > x86_64-lfs-linux-gnu-c++filtx86_64-lfs-linux-gnu-ranlib > x86_64-lfs-linux-gnu-elfeditx86_64-lfs-linux-gnu-readelf > x86_64-lfs-linux-gnu-gprof x86_64-lfs-linux-gnu-size > x86_64-lfs-linux-gnu-ld x86_64-lfs-linux-gnu-strings > x86_64-lfs-linux-gnu-ld.bfd x86_64-lfs-linux-gnu-strip > > suggesting that any non-x86_64 stuff has to come from the host ? There is not much to see in ch5-binutils-pass1. > > Then again, you've stated that your sucessful build came from an > non-multilib host. Yes, see above. > FYI, my host (Ubuntu 1404 - yes. old, yes) has > > Binutils: (GNU Binutils for Ubuntu) 2.24 > gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4 > (Ubuntu EGLIBC 2.19-0ubuntu6.14) 2.19 > > so is a little diferent to what the Multilib book suggests things > have been tested against, bis: > > Binutils-2.25 (Versions greater than 2.31.1 are not recommended as > they have not been tested) > GCC-4.9 including the C++ compiler, g++ (Versions greater than 8.2.0 > are not recommended as they have not been tested) > Glibc-2.11 (Versions greater than 2.28 are not recommended as they > have not been tested) H, usually we do not dig around in issues with hosts doesn't match the requirements. Anyway, the "oldest" thing i have around is a CentOS7. Tried to build there, but failed with quite simmilar messages at ch5-gcc-pass1. > I think I may find the best way forwards to be one in which I build an > non-Multilib LFS 8-3 > and then use that to boostrap the Multilib one, as that would give me > a "host" with > > Binutils-2.31.1 > GCC-8.2.0 > Glibc-2.28 Thats what I'd suggest - then we have a well defined environment. Make sure that the running kernel is 32-bit-enabled [*] 64-bit kernel ... Executable file formats / Emulations ---> [*] IA32 Emulation [*] x32 ABI for 64-bit mode > > Just out of interest then, what are the Binutils, GCC, Glibc versions on > the "non-multilib" host that your Multilib buils suceeds ? The only non-ML (but kernel is 32bit-enabled) i have around is a LFS- 8.1+ machine which is actually from 2018/01/01. gcc is 7.2.0, glibc is 2.26, binutils-2.29.1. There the built ran smoothly. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Multilib patch
Hi Kevin, Am Samstag, den 05.01.2019, 18:56 +0800 schrieb Kevin Buckley via lfs- dev: > ... > > Failed at the second hurdle. > > The first GCC pass gets as far, in the `make`, as building the included zlib > and, whilst configuring that, ends with > Adding multilib support to Makefile in ../../zlib > multidirs=32 x32 > with_multisubdir= > Running configure in multilib subdirs 32 x32 > pwd: /home/lfs/gcc-8.2.0/build/zlib > Running configure in multilib subdir 32 > pwd: /home/lfs/gcc-8.2.0/build > mkdir 32 > configure: creating cache ./config.cache > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu > checking target system type... x86_64-lfs-linux-gnu > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for x86_64-pc-linux-gnu-strip... no > checking for strip... strip > checking for a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether to enable maintainer-specific portions of Makefiles... no > checking for x86_64-pc-linux-gnu-gcc... gcc -m32 > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc -m32 accepts -g... yes > checking for gcc -m32 option to accept ISO C89... unsupported > checking for style of include used by make... GNU > checking dependency style of gcc -m32... gcc3 > checking how to print strings... printf > checking for a sed that does not truncate output... /bin/sed > checking for grep that handles long lines and -e... /bin/grep > checking for egrep... /bin/grep -E > checking for fgrep... /bin/grep -F > checking for ld used by gcc -m32... ld -m elf_x86_64 > checking if the linker (ld -m elf_x86_64) is GNU ld... yes > checking for BSD- or MS-compatible name lister (nm)... nm > checking the name lister (nm) interface... BSD nm > checking whether ln -s works... yes > checking the maximum length of command line arguments... 3458764513820540925 > checking whether the shell understands some XSI constructs... yes > checking whether the shell understands "+="... yes > checking for ld -m elf_x86_64 option to reload object files... -r > checking for x86_64-pc-linux-gnu-objdump... objdump > checking how to recognize dependent libraries... pass_all > checking for x86_64-pc-linux-gnu-ar... ar > checking for x86_64-pc-linux-gnu-strip... strip > checking for x86_64-pc-linux-gnu-ranlib... ranlib > checking command to parse nm output from gcc -m32 object... failed > checking how to run the C preprocessor... /lib/cpp > checking for ANSI C header files... no > checking for sys/types.h... no > checking for sys/stat.h... no > checking for stdlib.h... no > checking for string.h... no > checking for memory.h... no > checking for strings.h... no > checking for inttypes.h... no > checking for stdint.h... no > checking for unistd.h... no > checking for dlfcn.h... no > checking for objdir... .libs > checking if gcc -m32 supports -fno-rtti -fno-exceptions... no > checking for gcc -m32 option to produce PIC... -fPIC -DPIC > checking if gcc -m32 PIC flag -fPIC -DPIC works... yes > checking if gcc -m32 static flag -static works... no > checking if gcc -m32 supports -c -o file.o... yes > checking if gcc -m32 supports -c -o file.o... (cached) yes > checking whether the gcc -m32 linker (ld -m elf_x86_64 -m elf_i386) > supports shared libraries... yes > checking dynamic linker characteristics... configure: error: Link > tests are not allowed after GCC_NO_EXECUTABLES. > make[1]: *** [configure-zlib] Error 1 > make[1]: Leaving directory `/media/sda5/home-lfs/gcc-8.2.0/build' > make: *** [all] Error 2 > > > Has my applying the Multilib patch not done all it should - it applied cleanly > as I noted above. If it applied cleanly, then it should have touched everything needed. Strange enough - i cannot reproduce this issue, just did a build on a non-multilib host and it goes fine (so far, now at gcc-pass2 in chap- 5). Can you have a look into the config.log file - maybe there is something more informative? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] VirtualBox running on LFS
Am Sonntag, den 18.11.2018, 23:35 + schrieb Ken Moffat via lfs- dev: > On Sun, Nov 18, 2018 at 10:52:54PM +0100, Thomas Trepl via lfs-dev wrote: > > Hi all, > > > > today VirtualBox started on a LFS host and i was able to start a VM > > with it. I'm definitely not saying it is fully functional, much more > > testing and bug fixing might be required for that. It is for sure not > > "production ready" yet as some errors are still there. It does not > > work to start machines using the GUI, but it is possible to start them > > using the CLI tool "VBoxManage". So i think its some kind of > > configuration issue, fundamently it seems that VBox is working. > > Cool, and congratulations. Just one question. > > > Well, i forgot that the kernel i run > > wasn't 32-bit enabled. Booting the right kernel, all was fine again. > > In kernel config, don't forget to set > > > >Executable file formats / Emulations ---> > > [*] IA32 Emulation > > < |M|*> IA32 a.out support > > [*] x32 ABI for 64-bit mode > > > IA32 is clearly needed for 32-bit support, no argument about that. > > But x32 is a different thing entirely, and I wonder if anybody > (except gentoo and perhaps debian) use it ? In particular, gcc and > g++ need -mx32. > > https://en.wikipedia.org/wiki/X32_ABI > > But I see that you do have libx32 in your diff, so perhaps you > really are using it. mx32 is in the patch more or less just to have it. I also do not need it for the VirtualBox stuff. It was more an exercise when doing multilib as the configure options and CFLAGS are different to m32 as well as to m64. Alain was interested in mx32 to limit memory usage of tasks to 4GB on a large system with 32 or 64 GB memory. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gcc fails to build
Am Freitag, den 09.11.2018, 10:19 -0600 schrieb Bruce Dubbs via lfs-
dev:
> On 11/09/2018 09:44 AM, Pierre Labastie via lfs-dev wrote:
> > On 09/11/2018 14:30, Pierre Labastie via lfs-dev wrote:
> > > On 09/11/2018 13:38, John Frankish via lfs-dev wrote:
> > > > > As an aside, what is the first line of the current script meant to
> > > > > expand to?
> > > > >
> > > > > $ for file in gcc/config/{linux,i386/linux{,64}}.h
> > > > >
> > > > > ...
> > Hmm, sorry, I see that your system is tinycore64. AFAICS, there is no
> > dash shell in tinycore (unless you compiled it). It seems to have only
> > bash... But maybe it is a stripped down version of bash, not
> > interpreting double {. Or maybe you are using busybox shell (testing it
> > on debian shows it does not interpret the double {).
>
> The issue of dash vs bash should be handled in the version-check.sh
> script.
Maybe we add two lines to the version-check.sh:
X=$( echo X{1,2{,.{1,2}}} )
[ "$X" == "X1 X2 X2.1 X2.2" ] || \
echo "ERROR: Shell doesn't handle brace expansion correctly"
unset X
or something like that...
--
Thomas
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] gcc fails to build
Am Freitag, den 09.11.2018, 11:15 + schrieb John Frankish via lfs-
dev:
> > > > > Ref:
> > > > >
> > > > > Linux From Scratch - Version SVN-20181029 Chapter 5. Constructing a
> > > > > Temporary System 5.5. GCC-8.2.0 - Pass 1
> > > > >
> > > > > Using the latest script to update the dynamic linker results in gcc
> > > > > failing to build.
> > > > >
> > > > > Using a previous script fixes the problem.
> > > > >
> > > > > Details below.
> > > > >
> > > > >
> > > > >
> > > > > This script:
> > > > >
> > > > > for file in gcc/config/{linux,i386/linux{,64}}.h
> > > > > do
> > > > > cp -uv $file{,.orig}
> > > > > sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&@g' \
> > > > > -e 's@/usr@/tools@g' $file.orig > $file
> > > > > echo '
> > > > > #undef STANDARD_STARTFILE_PREFIX_1
> > > > > #undef STANDARD_STARTFILE_PREFIX_2
> > > > > #define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"
> > > > > #define STANDARD_STARTFILE_PREFIX_2 ""' >> $file
> > > > > touch $file.orig
> > > > > done
> > > > >
> > > > This script has been in the book for a couple of years. It is hard to
> > > > believe that nobody else has seen a failure if it is wrong.
> > > >
> > > > Maybe your system is not recognized as either i386 or x86_64, or not as
> > > > linux?
> > > >
> > > > Are you building on a Mac, Unix derivate or raspberry pi? What is the
> > > > response of the " arch" command?
> > > >
> > > I'm building on a linux machine recognised as x86_64 and I
> > > tried three separate times...
> > >
> > Could it be a copy/paste artifact, such as a space after '\' at the end
> > of a line?
> > GNU_TARGET_OS_etc is defined in gcc/config/linux.h, and shouldn't
> > be modified by the said script; unless possibly if there is a typo.
> > Sorry if I sound like the error comes from your side (script, our unusual
> > system, I rule out LFS and LFS_TGT variable settings, since it seems to work
> > with the old script), but really, after 2 years, somebody should have
> > spotted
> > the same error as you.
> >
> I don't think that the new script has been in use as much as two years, since
> I last built using the LFS instructions a year ago with the old script. This
> being said, yes, you would have thought that somebody else would have noticed
> it.
Wouldn't believe that editors update instructions of those essential
tools without testing. Anyway, the scripts works, I just verified it
in this minute here again...
> It could be a copy paste error ...
or something else in the build environment. I assume you double-
checked a thousand times that all the envvars are set proper and the
host-gcc is not damaged somehow? (well shouldn't - otherwise binutils
wouldn't be compiled)
> but I tried three times with the new script and it worked first time when
> copy pasting the old script...
Which shell are you using?
--
Thomas
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] gcc fails to build
Am Freitag, den 09.11.2018, 07:55 + schrieb John Frankish via lfs-
dev:
> > > Ref:
> > >
> > > Linux From Scratch - Version SVN-20181029
> > > Chapter 5. Constructing a Temporary System
> > > 5.5. GCC-8.2.0 - Pass 1
> > >
> > > Using the latest script to update the dynamic linker results in gcc
> > > failing to build.
> > >
> > > Using a previous script fixes the problem.
> > >
> > > Details below.
> > >
> > >
> > >
> > > This script:
> > >
> > > for file in gcc/config/{linux,i386/linux{,64}}.h
> > > do
> > > cp -uv $file{,.orig}
> > > sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&@g' \
> > > -e 's@/usr@/tools@g' $file.orig > $file
> > > echo '
> > > #undef STANDARD_STARTFILE_PREFIX_1
> > > #undef STANDARD_STARTFILE_PREFIX_2
> > > #define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"
> > > #define STANDARD_STARTFILE_PREFIX_2 ""' >> $file
> > >touch $file.orig
> > > done
> > >
> > This script has been in the book for a couple of years. It is hard to
> > believe
> > that nobody else has seen a failure if it is wrong.
> >
> > Maybe your system is not recognized as either i386 or x86_64, or not as
> > linux?
> >
> > Are you building on a Mac, Unix derivate or raspberry pi? What is the
> > response of the " arch" command?
> >
> I'm building on a linux machine recognised as x86_64 and I tried three
> separate time...
whats the output of "uname -a" ? (i assume Julius meant this by "arch"
command).
Append the output of "gcc -v --version"
--
Thomas
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-support] Incorrect MD5 for /development/lfs-bootscripts-20170626.tar.bz2
Am Freitag, den 29.12.2017, 10:05 -0600 schrieb Bruce Dubbs: > Ken Moffat wrote: > > On Fri, Dec 29, 2017 at 01:10:06PM +, Nate Costello wrote: > > > I'm getting an incorrect hash for the lfs-bootscripts file. This is using > > > the development branch. Can anyone attempt to repeat my finding or > > > provide guidance? I apologize in advance if it is bad form to email this > > > list about the development version. > > > > > > > First, it's perfectly fine to ask about problems building the dev > > book on this list. But, based on what I note below I'll Cc: the > > -dev list because I didn't expect this. > > > > > Thanks, > > > > > > Nate > > > > > > File path: > > > > > > http://www.linuxfromscratch.org/lfs/downloads/development/lfs-bootscripts-20170626.tar.bz2 > > > > > > Supposed Correct Hash: > > > > > > 4d886e7f5c3b092991cd0c56f3d8aa31 > > > > > > Listed at: > > > > > > http://www.linuxfromscratch.org/lfs/view/development/chapter03/packages.html > > > > I wonder if we have somehow switched to regenerating these ? My > > local copy (downloaded on 19th July) has > > > > c8c20c854d7590662ae04f21949566ea > > > > The 8.1 book, which uses these, says > > > > d4992527d67f28e2d0c12e3495422eab > > And that matches what is in > http://www.linuxfromscratch.org/lfs/downloads/8.1/lfs-bootscripts-20170626.tar.bz2 > > The script that rebuilds the book daily also repackages the boot scripts > and the timestamps will change each time, even though the content does not. > > On my local system, the tarballs are not rebuilt without a change to the > file name because I do not do a fresh checkout of the sources into an > empty directory like the daily scripts do. > > I could update the md5sum in the on-line book daily, but I think that > would also cause problems. > > I suppose I could come up with a way to put in a note that would only > generate in the development versions of the book(s), but right now I think > it is more effort than it is worth. The daily build script has been > unchanged for 18 months and this it the first anyone noticed. > > > All this applies to the lfs systemd development version and blfs tarballs > also. Today I came across that issue too because i want to build a 8.3 system (for some reference purposes) and failed because of that chksum mismatches. Currently there are again 3 chksums for lfs-bootscripts- 20180820.tar.bz2 - one in 8.3, one in devel and one at the file i previously downloaded in August - all different ... Isn't there really no way to (re)package the bootscripts a) when changes has been made AND b) with a new version number? -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
