Re: FC6 (x86_64) as a host system
El Martes, 20 de Marzo de 2007 06:18, Fix escribió: If you're building 64-bit *LFS system WITHOUT use of the cross compilation, you would need the 64-bit host system, I guess. That's what I do. And I think that system wouldn't be neither Cross nor Beyond LFS. Right, but the LFS book is intended only for x86 -- x86 builds. For not cross-compiled builds on others arches, included x86-64 -- x86-64 builds, you may need a different sets of instructions and/or patches that currently aren't discussed on any *LFS book. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Remarks on LFS-6.2
On Tuesday 20 March 2007 02:26, Fix wrote: So that I'm waiting for anyone else to confirm or to reject the report. Using jhalfs r3335 to complete a build of LFS SVN-20070319 on an i686 box, only annexc and tst-cancel1.out fail for me, and test-installation.pl reports success too. While the current development book is quit a way ahead of where LFS-6.2 was in terms of the toolchain used, I've never seen many failures at all in any of the test suites, let alone any in the toolchain. I'd be interested if you can reproduce your tens of failures using jhalfs, if only to rule out a) mistakes in any build scripts you might be using and/or b) mistakes made when copying/pasting/typing the commands from the book. scripts or running the commands by hand). Again, please note that LFS doesn't currently support 64-bit architectures. If you're wanting to build LFS on such a box, the recommended method is to use the CLFS instructions. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Linux Test Project
Just a note to say I was trying out the LTP today on my 6.2 test system. http://ltp.sourceforge.net/ I ran the tests and got four failures: mincore01 FAIL 1 gf15 FAIL 1 gf17 FAIL 1 gf18 FAIL 1 gf stands for growfiles and the reason they failed is that I ran out of disk space (I had 1.3G free). When I created a new 10G partition for them, the gf tests passed. The mincore01 gives: $ sudo ./mincore01 mincore011 PASS : expected failure: errno = 22 (Invalid argument) mincore012 PASS : expected failure: errno = 14 (Bad address) mincore013 FAIL : call succeeded unexpectedly mincore014 PASS : expected failure: errno = 12 (Cannot allocate memory) Details: test3: Invoke mincore() when the vector points to an invalid address. This may be a bug in the test suite. The address they specify is NULL, but the length is zero. In other words, it looks like LFS is a pretty strong system (If you didn't already know that). -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS-6.3 status update
Hi folks, Progress appears to being made toward a 6.3 release. We currently have 9 tickets to resolve before we can push another release out[0]. I'm happy to postpone the rendering toolchain related bugs #1947 (fop-0.93) and its dependency of #1956 (docbook-xsl-1.72.1) if upstream aren't in a position to make a release in time. #1893 (docbook-4.5) has a patch available so that's a no-brainer really. I don't think any of the 6 remaining tickets requires much effort, just someone with the required knowledge and motivation to propose a solution and/or provide a patch. I'll be on holiday from 2007-03-23 to 2007-04-06 and am unlikely to be able to deal with any LFS issues during that time. That said, if anyone wants to try and find me in a bar in North Carolina, I might be persuaded to deal with LFS stuff, in exchange for a beer or 2 of course :-) Regards, Matt. [0] http://wiki.linuxfromscratch.org/lfs/report/3 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LTP failure
I've been trying to figure out why the attached file fails on my LFS systems. It does not fail on FC or RHEL kernels. I'd appreciate it if some of you could run the attached program ans send me the results. You just run the binary. If you don't want to do that, the full source to is at http://prdownloads.sourceforge.net/ltp/ltp-full-20070228.tgz?download -- Bruce mincore01 Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LTP failure
On 3/20/07, Bruce Dubbs [EMAIL PROTECTED] wrote: I've been trying to figure out why the attached file fails on my LFS systems. It does not fail on FC or RHEL kernels. I'd appreciate it if some of you could run the attached program ans send me the results. I got all passes on my system. $ ./mincore01 mincore011 PASS : expected failure: errno = 22 (Invalid argument) mincore012 PASS : expected failure: errno = 14 (Bad address) mincore013 PASS : expected failure: errno = 12 (Cannot allocate memory) mincore014 PASS : expected failure: errno = 12 (Cannot allocate memory) This is on linux-2.6.20.1/glibc-2.3.6. I have some of the DIY tweaks for the toolchain build. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.3 status update
On 3/20/07, Matthew Burgess [EMAIL PROTECTED] wrote: Progress appears to being made toward a 6.3 release. We currently have 9 tickets to resolve before we can push another release out[0]. Yeah, that'd be great. I'm happy to postpone the rendering toolchain related bugs #1947 (fop-0.93) and its dependency of #1956 (docbook-xsl-1.72.1) if upstream aren't in a position to make a release in time. #1893 (docbook-4.5) has a patch available so that's a no-brainer really. The render stuff could probably be punted, but it'd be nice to use the new XSL stylesheets if possible. Nothing to lose sleep over, though. I don't think any of the 6 remaining tickets requires much effort, just someone with the required knowledge and motivation to propose a solution and/or provide a patch. I'll play with the bash testsuite ones using the fix Jeremy and I discussed a while back. As stated, we can use the su from Ch. 5 coreutils, but it should probably not be called su to keep a non-suid version out of the PATH. I'll be on holiday from 2007-03-23 to 2007-04-06 and am unlikely to be able to deal with any LFS issues during that time. That said, if anyone wants to try and find me in a bar in North Carolina, I might be persuaded to deal with LFS stuff, in exchange for a beer or 2 of course :-) I'm also gonna be out of town from 2007-03-28 to 2007-04-09 and will almost certainly be out of the mix the entire time. Unless someone wants to bring a laptop to Honduras/Guatemala. A couple cold ones, too. I'll be trying to wrap up the toolchain and bootscript stuff I posted about over the past week or so before I leave. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LTP failure
Dan Nicholson wrote:
On 3/20/07, Bruce Dubbs [EMAIL PROTECTED] wrote:
I've been trying to figure out why the attached file fails on my LFS
systems. It does not fail on FC or RHEL kernels.
I'd appreciate it if some of you could run the attached program ans send
me the results.
I got all passes on my system.
$ ./mincore01
mincore011 PASS : expected failure: errno = 22 (Invalid argument)
mincore012 PASS : expected failure: errno = 14 (Bad address)
mincore013 PASS : expected failure: errno = 12 (Cannot allocate memory)
mincore014 PASS : expected failure: errno = 12 (Cannot allocate memory)
This is on linux-2.6.20.1/glibc-2.3.6. I have some of the DIY tweaks
for the toolchain build.
Thanks Dan. I'm really puzzled about this. I pared the code down to
what I have below. compile with `gcc min.c -o min`.
For me, if I do ./min, I get:
PAGESIZE=4096
global_len=8192
global_pointer=0xb7fda000
alloc=2
Result=0
global_vec: 01 01 01 01 01 01
Which is a FAIL. Bit if I do `./min anything`, I get:
argc=2
PAGESIZE=4096
global_len=8192
global_pointer=0xb7f78000
alloc=2
Result=-1
global_vec: 01 01 00 00 00 00
which is a PASS.
The operation we are testing is mincore which is a direct call to the
kernel. The code is in mm/mincore.c.
Its like something is not getting initialized until the printf is run.
My kernel is 2.6.16.27-lfs62-a. I don't see anything in the config that
would make a difference. It's a mystery to me.
-- Bruce
--
cat EOF min.c
#include fcntl.h
#include errno.h
#include sys/mman.h
#include stdlib.h
#include unistd.h
#include sys/types.h
#include sys/stat.h
#include string.h
#include stdio.h
static intPAGESIZE;
static char file_name[]= fooXX;
static char* global_pointer = NULL;
unsigned char*global_vec = NULL;
static intglobal_len = 0;
static intfile_desc = 0;
int main(int ac, char **av)
{
int i;
char* buf;
unsigned char vect[6] = {0,0,0,0,0,0};
if ( ac 1 ) printf(argc=%d\n, ac);
PAGESIZE = getpagesize();
/* global_pointer will point to a mmapped area of global_len bytes */
global_len = PAGESIZE*2;
buf = (char*)malloc(global_len);
memset(buf,42,global_len);
/* create a temporary file */
file_desc = mkstemp(file_name);
/* fill the temporary file with two pages of data */
write(file_desc,buf,global_len);
free(buf);
/* map the file in memory */
global_pointer = (char *)mmap(NULL,global_len,
PROT_READ|PROT_WRITE|PROT_EXEC,MAP_SHARED,file_desc,0);
i = mincore((void*)global_pointer, (size_t)(global_len*5), vect);
printf(PAGESIZE=%d\n, PAGESIZE);
printf(global_len=%d\n, global_len);
printf(global_pointer=0x%x\n, (unsigned int)global_pointer);
//printf(global_vec=0x%x\n, (unsigned int)global_vec);
printf(alloc=%d\n, (global_len+PAGESIZE-1) / PAGESIZE );
printf(Result=%d\n, i);
printf(global_vec: %02x %02x %02x %02x %02x %02x\n,
vect[0], vect[1], vect[2], vect[3], vect[4], vect[5]);
}
EOF
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: ICA diff in cc1 and cc1plus
On 3/19/07, Dan Nicholson [EMAIL PROTECTED] wrote:
So, it seems this difference is embedded in cc1 and can't be stripped
out after the build. I'm assuming that the original difference is just
debugging symbols like would normally be the case. I'll try to narrow
that down further, but this may be a false positive ICA regression.
I took a look at the diff of the `objdump -s' output from the
unstripped cc1-dummy in each iteration. All the differences were in
the .debug sections, so I think I can say that the difference in cc1
and cc1plus can be ignored as a result of the embedded checksum. I
still don't know why this isn't the case in DIY.
Attached are two patches to add the glibc branch update patch in Ch. 5
and force /usr/include to be used as the preferred system include
directory after the toolchain re-adjustment.
--
Dan
Index: BOOK/chapter05/glibc.xml
===
--- BOOK/chapter05/glibc.xml (revision 7969)
+++ BOOK/chapter05/glibc.xml (working copy)
@@ -37,6 +37,11 @@
sect2 role=installation
titleInstallation of Glibc/title
+paraApply a patch to obtain various fixes that the upstream maintainers
+have provided:/para
+
+screenuserinputpatch -Np1 -i ../glibc-branch_update-patch;/userinput/screen
+
paraThe Glibc documentation recommends building Glibc outside of the source
directory in a dedicated build directory:/para
Index: BOOK/chapter06/gcc.xml
===
--- BOOK/chapter06/gcc.xml (revision 7969)
+++ BOOK/chapter06/gcc.xml (working copy)
@@ -161,19 +161,20 @@
href=readjusting.xml
xpointer=xpointer(//[EMAIL PROTECTED]'g'])/
+screen role=nodumpuserinputgrep -B2 '^ /usr/include' dummy.log/userinput/screen
+
xi:include xmlns:xi=http://www.w3.org/2003/XInclude;
href=readjusting.xml
xpointer=xpointer(//[EMAIL PROTECTED]'h'])/
+screencomputeroutput#include lt;...gt; search starts here:
+ /usr/lib/gcc/i686-pc-linux-gnu/gcc-version;/include
+ /usr/include/computeroutput/screen
+
xi:include xmlns:xi=http://www.w3.org/2003/XInclude;
href=readjusting.xml
xpointer=xpointer(//[EMAIL PROTECTED]'i'])/
-screencomputeroutputSEARCH_DIR(/usr/i686-pc-linux-gnu/lib)
-SEARCH_DIR(/usr/local/lib)
-SEARCH_DIR(/lib)
-SEARCH_DIR(/usr/lib);/computeroutput/screen
-
xi:include xmlns:xi=http://www.w3.org/2003/XInclude;
href=readjusting.xml
xpointer=xpointer(//[EMAIL PROTECTED]'j'])/
@@ -182,6 +183,11 @@
href=readjusting.xml
xpointer=xpointer(//[EMAIL PROTECTED]'k'])/
+screencomputeroutputSEARCH_DIR(/usr/i686-pc-linux-gnu/lib)
+SEARCH_DIR(/usr/local/lib)
+SEARCH_DIR(/lib)
+SEARCH_DIR(/usr/lib);/computeroutput/screen
+
xi:include xmlns:xi=http://www.w3.org/2003/XInclude;
href=readjusting.xml
xpointer=xpointer(//[EMAIL PROTECTED]'l'])/
@@ -218,6 +224,14 @@
href=readjusting.xml
xpointer=xpointer(//[EMAIL PROTECTED]'t'])/
+xi:include xmlns:xi=http://www.w3.org/2003/XInclude;
+href=readjusting.xml
+xpointer=xpointer(//[EMAIL PROTECTED]'u'])/
+
+xi:include xmlns:xi=http://www.w3.org/2003/XInclude;
+href=readjusting.xml
+xpointer=xpointer(//[EMAIL PROTECTED]'v'])/
+
/sect2
sect2 id=contents-gcc role=content
Index: BOOK/chapter06/readjusting.xml
===
--- BOOK/chapter06/readjusting.xml (revision 7969)
+++ BOOK/chapter06/readjusting.xml (working copy)
@@ -44,9 +44,10 @@
linkend=ch-tools-toolchaintechnotes role=,/ if necessary./para
/important
-screenuserinputgcc -dumpspecs | \
-perl -p -e 's@/tools/lib/ld-linux.so.2@/lib/[EMAIL PROTECTED];' \
--e '[EMAIL PROTECTED]:[EMAIL PROTECTED]/usr/lib/ @g;' gt; \
+screenuserinputgcc -dumpspecs | sed \
+-e 's@/tools/lib/ld-linux.so.2@/lib/[EMAIL PROTECTED]' \
+-e '/\*startfile_prefix_spec:/{n;[EMAIL PROTECTED]@/usr/lib/ @}' \
+-e '/\*cpp:/{n;[EMAIL PROTECTED]@ -isystem /usr/[EMAIL PROTECTED]' gt; \
`dirname $(gcc --print-libgcc-file-name)`/specs/userinput/screen
paraIt is a good idea to visually inspect the specs file to verify the
@@ -57,7 +58,7 @@
as expected. To do this, perform the following sanity checks:/para
screen role=nodump os=auserinputecho 'main(){}' gt; dummy.c
-cc dummy.c -Wl,--verbose amp;gt; dummy.log
+cc dummy.c -v -Wl,--verbose amp;gt; dummy.log
readelf -l a.out | grep ': /lib'/userinput/screen
para os=bIf everything is working correctly, there should be no errors,
@@ -80,44 +81,54 @@
/usr/lib/crti.o succeeded
/usr/lib/crtn.o succeeded/computeroutput/screen
- para os=gNext, verify that the new linker is being used with the correct search paths:/para
+ para os=gVerify that the compiler is searching for the correct header
+ files:/para
-screen role=nodump os=huserinputgrep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'/userinput/screen
+screen role=nodumpuserinputgrep -B1 '^ /usr/include'
Re: ICA diff in cc1 and cc1plus
On 3/20/07, Dan Nicholson [EMAIL PROTECTED] wrote:
Attached are two patches to add the glibc branch update patch in Ch. 5
and force /usr/include to be used as the preferred system include
directory after the toolchain re-adjustment.
I should mention that I changed the specs adjustment to use sed
because I don't really know perl. If anyone wants to keep it in perl,
feel free to provide the needed command. What's in the patch is this:
gcc -dumpspecs | sed \
-e 's@/tools/lib/ld-linux.so.2@/lib/[EMAIL PROTECTED]' \
-e '/\*startfile_prefix_spec:/{n;[EMAIL PROTECTED]@/usr/lib/ @}' \
-e '/\*cpp:/{n;[EMAIL PROTECTED]@ -isystem /usr/[EMAIL PROTECTED]' \
`dirname $(gcc --print-libgcc-file-name)`/specs
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
