Re: Merging the jh branch to trunk

2007-09-14 Thread Jeremy Huntwork
M.Canales.es wrote:
> Don't should that references be left-out until x86_64 support merge?
> 

If it happens to be me that applies these patches this weekend, I'll 
strip that stuff out, too.

--
JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)

2007-09-14 Thread Jeremy Huntwork
Greg Schafer wrote:
> But the worst part IMHO has already been pinpointed by Bruce in that it
> will encourage novice users to play with `--with-arch=my-uber-cool-cpu'.
> This isn't bad in itself but it can lead to problems. For example, it has
> been well known for years that you cannot compile Glibc with a GCC that
> was configured as `--with-arch=i686' (unless you patch Glibc). It bombs
> out due to conflicts in GCC preprocessor macros with Glibc assembler code.
> This is arguably a bug in Glibc, but the fact that Glibc devs refuse to
> fix it indicates rather strongly that CFLAGS is the correct way to build
> Glibc. It also proves that CC="gcc -march=i?86" is wrong for Glibc. To
> clarify, if you give CFLAGS to Glibc configure, it will build .c files
> with those flags but it won't use them for .S files.

After doing some tests and a great deal of Googling I've come to agree 
with Greg's estimation, the above paragraph being part of the clincher. 
Setting '--with-arch=i486' for GCC results in it using '-march=i486' for 
*everything*, unless another -march option is specified. As the above 
example shows, that concept seems contrary to the intention of Glibc 
developers.

I did indeed test building GCC using --with=arch=i686, which would be 
the same as using CC="gcc -march=i686" for Glibc, and as Greg stated, it 
causes Glibc to bomb with assembler errors. Conversely, I tested 
building GCC without using --with-arch and then used 'CFLAGS=-march=i686 
-mtune=native -O2 -pipe' ../glibc-2.6.1/configure ...' and built 
successfully. It seems to prove that it's better to let the Glibc devs 
decide where to use -march.

--with-march=i486 works, but seems prone to breakage. I think if we want 
to introduce optimization into LFS, then we could do better, and more 
correctly, than just using --with-arch on GCC. Using CFLAGS with Glibc 
would allow for other cpu-types for the -march statement and the 
possiblie introduction of -mtune=native as Greg also suggested.

So, to summarize, I propose not using --with-arch, but use the following 
for Glibc:

CFLAGS="-march=i486 -O2 -pipe" ../glibc-2.6.1/configure ...etc.

Glibc requires some sort of optimization and -O2 seems safe. -pipe 
should also be safe on gnu systems and should speed up compile times by 
using pipes instead of temporary files.

Anyone have any comments or suggestions? If not, and unless Matt decides 
to do it first, I'll be applying the patches he created plus the above 
change to trunk by the end of the weekend.

--
JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: Which list for Ticket reports?

2007-09-14 Thread Bryan Kadzban
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

Jeremy Huntwork wrote:
> This is a minor thing and I'll work with whatever is felt is best,
> but I thought it might help open up discussion if the items in Trac
> were more visible to all interested in LFS development. Does anyone
> have any thoughts on this?

It doesn't really matter to me; either -dev or -book is fine.  But if
nobody else votes which way to go either, I'll say -dev.  :-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG6usNS5vET1Wea5wRA5KCAKDHJXLnY5q25XkV+I1+aH4aqh5X3wCglG1Y
DntnHEe5fxxOpx6TdJpMlrQ=
=a307
-END PGP SIGNATURE-
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Which list for Ticket reports?

2007-09-14 Thread Jeremy Huntwork
Hello All,

After some little thought on the matter, it seems to me that the Trac 
ticket reports go to the wrong list. I can understand why lfs-book is 
the right list for commits. Those who are interested in discussing 
development of the book don't necessarily need to see all the commit 
logs. However, the ticket system contains info as to what is (possibly) 
currently wrong with the book and suggested changes. Often items like 
this should be discussed before implementation. Therefore, it seems to 
me that instead of having the ticket messages go to the commit list, 
they really should be directed to the development list.

This is a minor thing and I'll work with whatever is felt is best, but I 
thought it might help open up discussion if the items in Trac were more 
visible to all interested in LFS development. Does anyone have any 
thoughts on this?

--
JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page