[Clfs-dev] (no subject)

[Andrew Bradford]

On Sat, 2 Feb 2013 13:45:42 GMT
"jennifer and kirk terrell" <knjterrell at mybluelight.com> wrote:

> I wanted to check somethings before constructing a patch, which I've
> attached, so here goes
> 
> 3.2     Binutils-2.21 is not available. There is a 2.21.1a package
> that I did not try, I went with 2.22.

For 2.22, before you submit a patch, can you check that it works well
with uClibc for ARM, MIPS and x86?  At least to be able to compile?

There is a bug in trac for an x86 issue with uClibc and binutils 2.21
[1].  If 2.22 works well for you, please send a patch with that update
or if you run into issues, please let me and the list know and I'll try
to help out.

[1]: http://trac.cross-lfs.org/ticket/876

>     I found that uClibc-0.9.31 and 0.9.32 were not compatible with
> binutils-2.22. 

Is it similar to [1] above?
Do you have a fix?
Does 0.9.33 fix the problem?

> 6.4  None is not a good setting for --with-fpu 
>     when compiling gcc I get the following error "Unknown fpu used in
> --with-fpu=none" 

That makes sense according to the gcc docs.

> 6.10 If --with-float is soft one shouldn't use --with-fpu
> 
>     See 6.4

It seems so, at least for GCC 4.6, maybe older versions allowed this
and it was missed in the change to GCC 4.6.

> 6.11 uClibc-0.9.33 does not need to be patched for use with
> binutils-2.22. If an additional patch of the config file is not done
> I get the following error "make: -gcc: Command not found"

Is this for the soft-float patch?  If so, that'd be good.  It was an
ugly hack fix anyway.

Can you explain the error you see in more detail?

> 6.12 If --with-float is soft one shouldn't use --with-fpu

Yes.  They mean the same thing.

> 7.4 Add make clean prior to copying the config file. Not required but
> likely a good practice if one has to restart after a change.

The instructions assume you've just unpacked.  A make clean shouldn't
be needed but probably is a good practice anyway.

Can you try using busybox's "make defconfig" instead of the book's
config patch?  If that works well, I'd like to get rid of all our
config patches.  If you could do this for all the combos of each arch
and endian and other assorted combos, I'd really appreciate it.
Maintaining the config patches is a pain.

> 16.1    remove the /sources directory.          

That's a valid thing to do.

When you send patches, can you send 1 patch per each of these things?
That way if we find some part of your patches don't work as expected we
can easily either not apply it or revert it without issue.  Git's
format-patch and send-email works well for sending patches.  Please
just note in either the cover letter or within each patch that these
are for the embedded book.

It'd also be good, in the future, to have a subject indicating that
you're talking about the embedded book.

Thanks,
 -Andrew