[gentoo-embedded] Re: uclibc buildroot/ toolchain

[Peter S. Mazinger]

On Sun, 14 Dec 2003, Daniel wrote:

> --[PinePGP]--------------------------------------------------[begin]--
>
> > Some proposals for uclibc.ebuild 20031206 (reading it only, not tested):
> >
> > 1. do not activate SYS_SIGLIST (and SYS_ERRLIST), they are obsoleted and
> > no SuSv3 requirement, probably will be removed, and they are easy to
> > replace (using sed if you like), there are not so many packages until now
> > where I needed it to patch.
> >
> > sys_siglist[sig] = strsignal(sig) /* util-linux */
> > sys_errlist[err] = strerror(err)  /* iputils, tcp_wrappers */
>
> The only reason I put these is was because the busybox 0.60.5 used one of
> them.
>
> > 2. use busybox and tinylogin cvs snapshots (or at least 1.0.0-pre4 for
> > busybox), the changes from 0.60.5 are massive.
>
> Sounds good - that will fix #1.

right, busybox-1.00-pre3/pre4 does not need them.

>
> > 3. I do not understand why WGET has to be set to true, if you have all
> > the needed files in sources/dl (DL_DIR), nothing will be downloaded.
>
> Its basically to remove the dependancy that wget exists. Someone may have
> removed this and I did want to put it as a dependancy since it realy didn't
> get used. The portage system will downloads the files from the SRC_URI.

Ok.

>
> > 4. check uclibc.config and -locale, they are not always in sync (as
> > of this writing UNIX98PTY_ONLY is different). My build procedure runs make
> > defconfig (getting defaults for arch), after that I add echo
> > "CONFIG_<option>=y/n" >> .config and rerun make oldconfig (look in
> > uclibc.spec). Easier though is to have only the locale config, copy to
> > .config ,echo "CONFIG_LOCALE=n" >> .config, make oldconfig to get
> > nonlocal.
>
> This is great. I was looking for the way to remove interactivity ;-).

Take a look at the attached uClibc.spec (rpm) to see how I proceed.
The same procedure works for busybox >= 1.00-pre.
Inspire yourself from my spec files at 
http://dev.gentoo.org/~solar/rpm_specs/
not sure of the location (mentioned in some earlier mail from solar).
I'll send him also all my specs/patches again, maybe he'll get it now ;-)

>
> > 5. No comment on src_install, do not know gentoo requirements,
>
> Gentoo creates a image before the install at
> ${D} /var/tmp/portage/uclibc-buildroot-0.9.23/image and this is forced to be
> empty at the start of src_install. I've sort of got to copy from staging_dir
> to ${D} which is a bit of a waste of space and time. More makefile hacking to
> fix this.
>
> > but check
> > the files in $ROOT/usr/lib/gcc-lib/*/version/include, I had here a
> > "fixed" zutil.h and linux/nls.h, there could be others too (my build
> > system was minimal at that moment)
>
> I've got that as a symlink like:
> /usr/lib/gcc-lib/i386-uclibc/0.9.23 -> /usr/i386-uclibc/lib

I do not know why you need this link.

It looks like a binutils requirement, I am building binutils with
make tooldir=/usr to get read of the /usr/arch-*/ structure. see 
binutils.spec

>
> The gcc-config (gentoo wrapper gcc/g++ that maps to specific compilers) looked
> for something in /usr/lib/... so I just symlinked an that seems to work. I
> need to verify this later.
>
> The linux/nls.h and the zutil.h are the standard kernel headers. I found a
> zutil.h in toolchain_build_$(ARCH)/gcc-3.3.2/zlib/zutil.h have you modified
> this one?
>
> > and it looks like all these get higher
> > priority as those installed in $ROOT/usr/include subdir (and you'll end up
> > building against different version of headers and libs)
>
> If you're cross compiling isn't this the desired behaviour? Yes I do need to
> somehow handle different kernel versions somehow - will think about later.
>
> I'm not sure totaly what you're refering to here but I will look into it a
> bit.

I'll try to explain it again:
gcc puts zlib.h into it's own include directory. Now you take the 
toolchain and are building zlib (a version that has a different zutil.h). 
Maybe this will work if the used flags that influence the include dirs (-I 
-nostdinc or appropiate) won't allow the usage of gcc's zutil.h. After 
that compile an application using zlib. Which zutil.h will be used if you 
do not force something special? As I understand it, gcc's includedir has 
the highest priority (this is my presumption, could be wrong), so you'll 
end up using different zutil.h and libz.[so,a]

I do remove all these addon files from gcc's include directory (I do not 
put them into package) take a look at gcc.spec

> I'm intested in incorportating your fixed files along the etdyn
and > propolice(?)  patches ones that Ned is also trying to get off you.

Attached, these are newer then those sent to the uclibc list, apply these.

The propolice patch includes the same ssp.c file as gentoo's glibc.
The changes to the last version sent to uclibc list (and also to Ned, 
but as looks like lost) are only of cosmetical. Some parts 
could get into 0.9.24 (if Erik will accept them, no answer yet). The PaX 
team considers the ldso.c patch as "not really an option, it's a bug).

The patch requires echo "CONFIG_PROPOLICE=y" >> .config

The etdyn/pie patches enforce no text relocation support in uClibc (as it 
would do the same PaX option), so no library will work, that has TEXTREL 
in it (and no binary built as ET_DYN/PIE as it behaves like a library). If 
you look at my uClibc.spec at the end of %install phase, I am doing a 
TEXTREL check, to be sure that the built libraries will really work 
(that's why I know that enabling PROFILING adds TEXTREL to libc.so)
I haven't really tested it w/ relocation support (only built one "hello 
world" binary, I am using exclusively the PaX option in my kernels, so 
probably I wouldn't have a chance to test it on such kernels. You can 
remove the requirement if you like to, for the hardened project if should 
be left as it is and force the environment to be fully PIC.
Also remove COMPLETELY_PIC from the config file, it's unused, but does not 
allow to disable the text relocation.

The patches require echo "CONFIG_PIE_SUPPORT=y" >> .config

>
> > 6. My changes to (non-locale) config are:
> > - CONFIG_PROFILING=n (for "use etdyn" it should be a requirement due to
> > TEXTREL in libc.so, checked up to cvs)
> > - PTHREADS_DEBUG_SUPPORT=n if non-debugging
> > - MALLOC_GLIBC_COMPAT=n
> > - UNIX98PTY_ONLY=y
> > - UCLIBC_HAS_SCANF_GLIBC_GLIBC_A_FLAG=n /* not really implemented */
> > - UCLIBC_HAS_TZ_FILE_READ_MANY=n /* we change only once /etc/TZ */
>
> Ok will incorporate this. A locale config would be the same right? or is there
> some other weird dependancy.

Comment on these:
UNIX98PTY_ONLY=y was changed recently to n in buildroot (due to some 
report of problems with building dropbear, I do not have the problem, it 
works for me)

MALLOC_GLIBC_COMPAT (return for malloc differs). This is what I am 
aware of: freeswan needs patch. I do not know how to test, if other 
packages are influenced by this behaviour (the freeswan patch was supplied 
by someone to the freeswan list). Erik Anderssen considers glibc's malloc
behaviour a bug (but enables this option in the configuration)

LOCALE:
If you are building in an environment where locales are not supported, 
then you need to use the pregenerated data, the locale data can't be 
rebuilt w/o support for setlocale().

I had also following scenario (I do not know how to simulate this in a
glibc env, setlocale() has to be somehow disabled to test):
clean uClibc environment (no glibc) built w/o locale, rebuilding uClibc w/ 
locale, if XLOCALE is enabled it will fail, so the only way to get the 
XLOCALE option is to build already the toolchain with it, afterwards (I 
mean building for the target) it is too late.

The referenced spec files are not all the time working for a toolchain (if 
you see the toolchain option in them, then it has to be set to 1, to get 
it work) so interpret them carefully (but they work in the clean uclibc 
env).

>
> > Best regards, Peter
>
> Thankyou kindly
>
> --
>
> Daniel Black
> --
> Proudly a Gentoo Linux User.
> GnuPG/PGP signed and encrypted email preferred
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x32A64DC8
> --[PinePGP]-----------------------------------------------------------
> gpg: WARNING: using insecure memory!
> gpg: please see http://www.gnupg.org/faq.html for more information
> gpg: Signature made Sun 14 Dec 2003 02:44:47 AM CET using DSA key ID 32A64DC8
> gpg: Can't check signature: public key not found
> PinePGP: Encryption backend encountered error.
> --[PinePGP]----------------------------------------------------[end]--
>

-- 
Peter S. Mazinger <ps.m@×××.net>   ID: 0xA5F059F2    NIC: IXUYHSKQLI
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

____________________________________________________________________
Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol.
Probald ki most! http://www.freestart.hu