a problem of making libXML2

_______________________________________________
Clfs-support mailing list
Clfs-support <at> lists.cross-lfs.org
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org

Re: a problem of making libXML2

xg du wrote:
> I meet a problem when making the libXML2-2.7.2(multilib64) according
> cblfs' method. I used the clfs multilib system and install the
> python2.5.2(multilib32 and multilib64) also according the cblfs' method.
> what should I do to fix this error ?
> CC="gcc -m64" USE_ARCH=64 ./configure --prefix=/usr
> --libdir=/usr/lib64 && make
> then I got the message below:
> [snip]
>
> /usr/include/python2.5/pyconfig.h:1:1: error: unterminated #ifndef
You need to go back and fix this header and create it as per the book,
it's clear that you have a typo.

Fix for clfs-embedded section 6.8 uClibc-0.9.30

_______________________________________________
Clfs-support mailing list
Clfs-support <at> lists.cross-lfs.org
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org

Re: Fix for clfs-embedded section 6.8 uClibc-0.9.30

Simon Haines wrote:
> Just to let the community know that there is a bug in the
> clfs-embedded book (from svn head) in section 6.8.
> The faulty command is: make CC="${CC} ${BUILD}"
>
I made the update in r4084. My original thought was to use make
CC="\$(CC) ${BUILD}" but the circular dep on make slipped my mind. I get
so used to using := in Makefiles wherever possible, It saves memory and
cpu usage by evaluating the expression right then and there instead of
waiting the variable is used. But you cant pass the parameter on the
command line.

I instead changed it to make CC="${CLFS_TARGET}-gcc ${BUILD}"

I think it's time to also look into modifying GCC so that the BUILD
variable is no-longer needed. I believe the only architecture this was
put in for was mips. It's probably a much better idea to do some spec
file patching then deal with a environment variable that can be
forgotten. It's just something to think about for the future.

building packages

_______________________________________________
Clfs-support mailing list
Clfs-support <at> lists.cross-lfs.org
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org

Re: building packages

Doug Reiland wrote:
>  
> I am still going thru the document. I am at section 6.4 gcc-4.2.4.
>  
> First, I hit the SSIZE_MAX undefined error in linux-host.c. I see a 
> couple of hits in the mailing-list, but no real solution. I am surprise 
> there isn't a patch for this if it is really a problem.

It's most likely due to some kind of user error.

> Second, so far I have built binutils and now gcc twice. I understand the 
> need for this, but am I suppose to create new build directories for 
> these the second time around. Maybe a miss something, and I don't want 
> to get too far down the road. As documented, you end up applying patches 
> twice (getting warnings),  and doing configure twice.
>  
> binutils errored the second time I built it, saying configuration 
> changed and there is an old config.cache laying around. I ended up doing 
> make distclean and rm all the config.cache files, but I am surprised 
> this isn't documented either.

Looks like someone is in serious need of closely re-reading the book...

> It seems like documentation should tells us to rm the untarr-ed source,

 From page 5.1...

"Important

After installing each package, both in this and the next chapters, 
delete its source and build directories, unless specifically instructed 
otherwise. Deleting the sources prevents mis-configuration when the same 
package is reinstalled later."

> untar again,

Also on 5.1...

"Important

Before issuing the build instructions for a package, the package should 
be unpacked as user clfs, and a cd into the created directory should be 
performed. The build instructions assume that the bash shell is in use."

Granted, it doesn't say anything about what to do when you install a 
package twice, but then it doesn't need to. You follow the exact same 
basic steps (untar and cd into the source dir) before every package 
installation.

apply patches,

Yet again, page 5.1...

"Several of the packages are patched before compilation, but only when 
the patch is needed to circumvent a problem. A patch is often needed in 
both this and the next chapters, but sometimes in only one or the other. 
Therefore, do not be concerned if instructions for a downloaded patch 
seem to be missing."

rm old build directories or create different
> ones, ...

And once more, surprise surprise, page 5.1. The above-pasted "Important" 
note specifies source AND BUILD dirs are to be removed.

> If patches are all the same the second phase, don't document the patch 
> steps.
>  
Well, since you are told to rm the old source, then you'll need to apply 
the patch(es) again when you install the 2nd time.

Next time, try actually reading the book before complaining about things 
that are supposedly not documented.

Re: building packages

On Fri, Dec 05, 2008 at 01:48:30PM -0500, Doug Reiland wrote:
> 
>  
> I am still going thru the document. I am at section 6.4 gcc-4.2.4.
>  
> First, I hit the SSIZE_MAX undefined error in linux-host.c. I see a couple of hits in the mailing-list, but
no real solution. I am surprise there isn't a patch for this if it is really a problem.
>  
> Second, so far I have built binutils and now gcc twice. I understand the need for this, but am I suppose to
create new build directories for these the second time around. Maybe a miss something, and I don't want to
get too far down the road. As documented, you end up applying patches twice (getting warnings),  and doing
configure twice. 
>  
> binutils errored the second time I built it, saying configuration changed and there is an old
config.cache laying around. I ended up doing make distclean and rm all the config.cache files, but I am
surprised this isn't documented either.
>  
> It seems like documentation should tells us to rm the untarr-ed source, untar again, apply patches, rm old
build directories or create different ones, ...
> If patches are all the same the second phase, don't document the patch steps.

 Sounds as if you missed the 'Important' note at the bottom of
section 5.1.

 I can see the SSIZE_MAX problem in an old post that google found,
and a workaround, but I've never encountered it.  Putting these two
things together, I tend to believe something has been misconfigured
(because it picked up files from an earlier build).

 If you ever find a patch is already applied, something is seriously
wrong.

ĸen
--

-- 
das eine Mal als Tragödie, das andere Mal als Farce
_______________________________________________
Clfs-support mailing list
Clfs-support <at> lists.cross-lfs.org
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org

Re: building packages

_______________________________________________
Clfs-support mailing list
Clfs-support <at> lists.cross-lfs.org
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org

Building a CLFS for the Linksys NSLU2 (ARM arch)

Hi there,

I'd like to know, if anybody ever tried building a CLFS for the
Linksys NSLU2, which uses an XScale-IXP42x processor, thats able to
run both low and big endian arm code.
If theres any experience, tell me :)

Greetings,
Christoph

_______________________________________________
Clfs-support mailing list
Clfs-support <at> lists.cross-lfs.org
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org

Re: Building a CLFS for the Linksys NSLU2 (ARM arch)

On Dec 13, 2008, at 8:09 AM, Christoph Pegel wrote:

> Hi there,
>
> I'd like to know, if anybody ever tried building a CLFS for the
> Linksys NSLU2, which uses an XScale-IXP42x processor, thats able to
> run both low and big endian arm code.
> If theres any experience, tell me :)
>
> Greetings,
> Christoph

If you aren't finding much info or help from other people you might  
try messaging the guys at http://www.nslu2-linux.org

William