> > 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.
>
> There are only five patches, so they don't come up very often. I did
> miss the perl sed, but will do that tomorrow. I do do a test build, so
> the perl sed doesn't hurt even if it is not needed and more.
>
> > 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.
>
> Thanks, I'll look at that too.
>
> > 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.
>
> We had some contact with the developer and I was waiting for a go-ahead
> from him.
I am the bc developer.
As of right now, I have released what I am planning on being the last
release with new features (2.0.0) along with a couple bug fix
releases.
Because LFS wants a stable bc ("stable" as in not changing much rather
than "stable" as in bug free), I am waiting for a month past the last
release to add the bc to LFS. This is to ensure that users in the
field do not report any bugs and require yet another release.
Last release was May 28, so June 28 is when I plan to let LFS know
that it is good to go.
> > 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...
>
> I'm hesitant to change the working instructions for gcc, but let us know
> the results of your testing.
>
> -- Bruce
>
> --
> http://lists.linuxfromscratch.org/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
