Initial setup of the `glibc' in the target root file system

After the glibc builts perfect, I have a problem in setting up the root !
How can I install the glibc (/lib) to the root file system. I tried to do a "perfect copy" of the root via `tar' from /usr/parisc/hppa-linux
to /tftpboot/apollo (my nfs mounted root).

But how can I prepare the .../etc/ld.so.cahce file or whatever is needed.
Using a ldconfig from the host fails, using the -r option for another root:

ldconfig -r /tftpboot/apollo

Ldconfig terminates without errors, but the system mounting my NFS-root crashes
with page fault or with "cannot find libc.6.so". Only the root of the palinux-0.5
image is working.
Which of the two error reaction occurs depends on the ldconfig and platform.
I tried ldconfig of RH-6.1 on intel and RH-6.2 on sparc.

Whats the correct way ?

With friendly regards
Christoph

-------------------------------------------------------------------------
private:	[email protected]
company:	[email protected]

[snip]

[snip]

"with page fault" is possibly due to the glibc bug I mentioned in
http://lists.parisc-linux.org/pipermail/parisc-linux/2001-February/011686.html

"cannot find libc.so.6" is a different problem, a result of cross-compiling glibc with --prefix different to final install location. Let's see if I can explain the problem...

Suppose you want to cross-compile the toolchain and glibc from an i686-linux system, and you have chosen --target=hppa-linux. Further suppose you decide to install to /usr/ on your host x86 system (This does work safely, despite various recipes recommending /usr/parisc, or /opt/parisc). Now when cross-compiling glibc, you obviously _don't_ want to install glibc on your host to /usr, as the glibc you create is an hppa-linux binary, which doesn't run very well on x86-linux! So the proper install destination for glibc is given by --prefix=/usr/hppa-linux. This is also the root of directories where your hppa-linux cross-tools will look first for libraries and system header files etc. If you chooes some other prefix (ie. not <compiler prefix>/<compiler target>) then you'll have problems cross compiling.

However, trying to install the glibc that works for a cross-compiler tool-chain to your target system, at a different location, fails miserably because shared libraries specify where to look for their "interpreter" (dynamic linker). Your cross-compiled glibc will be looking for /usr/hppa-linux/lib/ld.so.1, while a native glibc will look for /lib/ld.so.1. Also, a cross-compiled dynamic linker knows to look under /usr/hppa-linux/ for libraries and ld.so.cache. On the other hand, you probably want your libraries in their normal locations so that you don't accidentally use the wrong library.

Of course, it's very useful to be able to install your cross-compiled glibc to your target :-), and hopefully the above explanation suggests one way around the problems:
- Install your glibc to a temp dir on your nfs server
eg. "make install_root=/var/tmp/install"
- Move files from /var/tmp/install to /tftpboot/<proper locataion> It helps if you know what <proper location> is! Compile glibc native for x86 and install to another temp dir if you don't know.
- Make relative symbolic links in /tftpboot/.../usr/hppa-linux/lib/ to the shared libs you installed to /tftpboot/.../lib/
- ln -s ../../etc /tftpboot/.../usr/hppa-linux/etc too
- What else? Oh yeah, /usr/lib/libc.so and some of the files installed
to /usr/bin/ are text files, and some have paths to /usr/hppa-linux.
Edit them.

It would be nice if you could cross-compile glibc with --prefix=/usr, but last time I tried this, quite some time ago, it failed because /usr/include/ was being used for headers. Maybe there's an easy way around this.

Alan Modra

Linuxcare.  Support for the Revolution.

Hello again !

I have found the method working here.

The GLIBC must be built with the line:

make user-defined-trusted-dirs=/lib

This adds the `/lib' to the internal trusted search path, which is defined in the
generated files ./elf/trusted-dirs.{st,h}. After this the normal installation to the
configured prefix (in my case /usr/parisc/hppa-linux)

make install user-defined-trusted-dirs=/lib

and the installation to the NFS root directory can be done by repeating install with

make install user-defined-trusted-dirs=/lib
install_root=/tftpboot/apollo/root

On the workstation (booted from the palinux-0.5 root file system) I mounted my new
NFS root to /mnt and used the command

ldconfig -v -r /mnt

And after that I booted from tne new root, and the error was, that there was no inittab
and no process left......

So I have success !!!! (I know, that there is nothing to boot further, except the init
itself !!)

Now a further question. How to build successfully a `bash', with other tools (expect
strace) I have not so big problems.

The bash' built process has problems in configure' in a cross compiled environment.
It tries some functions via C examples, and they have difficulties to determine the
result of a compile option, as this is not native....

I tried with

	HOSTCC=gcc CC=hppa-linux-gcc ../configure --host=hppa-linux \
		 --prefix=/usr/parisc/hppa-linux 

Configure stops with:

checking for working alloca.h... yes
checking for alloca... yes
checking whether getpgrp takes no argument... configure: error: cannot check getpgrp if cross compiling

How to build a bash (I am always interested in building from the scratch (hobby)) !

With friendly regards

Christoph P.

-------------------------------------------------------------------------
private:	[email protected]
company:	[email protected]

Good. There's probably other ways around the problem too. Just be aware that installing glibc built with the above in your cross-compiling machine will probably be wrong. Looking in /lib will pick up x86 libraries instead of hppa-linux ones.

You can edit config.cache to set the correct values. Doing so can be a pain. It's probably easier and better to compile native.

Alan Modra

Linuxcare.  Support for the Revolution.

Point (1):

No you have no pain at this point. This `/lib' is GLIBC built in and is only
evaluated from the shared library loader (./elf/dl-load.c) at runtime (as
far as I understood the stuff). So this has no influence on any cross built
process. On the running binary (on the target machine) sees two "lib search
strings" one to `/usr/parisc/hppa-linux/lib' and one to '/lib'. The runnung
binary on the target (HP PA) can then try both and will find it in '/lib'.

The file ./elf/ld-load.c is the only one using this information as far I found
per `grep'.

But if I am wrong, please correct me.....

Point (2):

I will see...

With friendly regards

Christoph P.

-------------------------------------------------------------------------
private:	[email protected]
company:	[email protected]

I'd like to summarize the previously discussed procedure to build glibc on the target machine to install in the nfsroot tree.

Assume the evironment vars for the build tree are

MACH=i386-linux
DEST=/mnt/parisc
ROOT=/mnt
(The NFS root exported from the directory /tftpboot/nfsroot)

# The configuration command would be:
# (--prefix seems to be ignored when using install_root later)

HOSTCC=gcc CC=hppa-linux-gcc $ROOT/source/glibc/configure \
--prefix=$DEST --build=$MACH --host=hppa-linux \
--target=hppa-linux --with-headers=$ROOT/source/linux/include \
--disable-profile --without-cvs --enable-add-ons

# The build command

make user-defined-trusted-dirs=/lib

# the install command

make install user-defined-trusted-dirs=/lib \
install_root=/tftpboot/nfsroot

Sadly, the boot process stops when init starts. Any comments?

     Rafael

First of all, the make install has to be done twice !

One time for the tool chain to find the things like crt?.o, libs, etc.. For this the builtin tree is defined (given by --prefix).

make install user-defined-trusted-dirs=/lib

The second time install it to the nfs root file system

	make install user-defined-trusted-dirs=/lib \
	  install_root=/tftpboot/nfsroot

For the target the `/lib' is the builtin search path, for the cross tool chain the '/usr/parisc/hppa-linux/lib' (in my case).

AND A VERY IMPORTANT POINT: You have to run `ldconfig'. I tried this on the target machine (apollo 720) by booting from the NFS-ROOT of palinux-0.5 (I copied the contents of the CD to a path exported by NFS). After booting I mounted my new NFSROOT to `/mnt' and run
ldconfig -v -r /mnt

After that I could boot from the new root file system starting the `init' process (but nothing else....)

Another test to do is to use host's ldconfig fore that work:

ldconfig -v -r /tftpboot/apollo/root

or something like this...

Cheers
Christoph P.

  +--------V--------+	[email protected]
  |  A L C A T E L  |	-----------------------------
  +-----------------+	Phone: +43 1 27722 3706	
         T A S		Fax:   +43 1 27722 3955

export MACH=i386-linux
export DEST=~/parisk/palinux
export ROOT=~/parisk

HOSTCC=gcc CC=hppa-linux-gcc $ROOT/source/glibc/configure \
--prefix=$DEST/hppa-linux --build=$MACH \
--host=hppa-linux --target=hppa-linux \
--with-headers=$ROOT/source/linux/include --disable-profile \
--without-cvs --enable-add-ons
make MAKE="make -j 10" user-defined-trusted-dirs=/lib make install user-defined-trusted-dirs=/lib
make install user-defined-trusted-dirs=/lib \
install_root=/tmp/glibc

Then copied all the new files onto a second copy of nfsroot. Booted the original, mounted the second under /mnt and run:

	parisc:/etc# ldconfig -v -r /mnt

and I got this:

ldconfig: Can't open configuration file /mnt//etc/ld.so.conf: No such file or directory

I rebooted with the second nfsroot and got a login prompt. However, I can't run ldconfig again and I get this error msg.:

parisc:/etc# ldconfig -v       
ldconfig: Can't open configuration file
/usr1/users/raffo/parisk/palinux/hppa-linux/etc/ld.so.conf: No such file
or directory
/usr1/users/raffo/parisk/palinux/hppa-linux/lib:
ldconfig: Can't open directory
/usr1/users/raffo/parisk/palinux/hppa-linux/lib: No such file or
directory
ldconfig: Can't create temporary cache file
/usr1/users/raffo/parisk/palinux/hppa-linux/etc/ld.so.cache~: No such
file or directory

I I create those directories and a ld.so.conf, it works, but the files are out of place. Maybe if it were possible to configure and install the files in the x86 machine under a pseudo /, it would install properly. Would 'chroot' work here?

     Rafael

This is no error message, it's warning.

This happens if you build glibc with a prefix and then install it somewhere else. This cannot work.

I really don't understand who came up with these "strange" build instructions. For Linux builds of glibc where the result is actually used in the normal place (means in /lib and /usr/lib) you *always* have to configure with --prefix=/usr. While installing it one than can use the install_root make variable.

---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

The idea is to build glibc so you can place it in the root directory of your parisc tree.

I saw this post that mentions how to build glibc using the cross compiler and then installing it in the nfsroot. The instructions are for installing glibc in a separate tree. I'm just learning how to use the install_root option.

It's no so "strange", how about these options now?:

export MACH=i386-linux
export DEST=/usr
export ROOT=~/parisk

HOSTCC=gcc CC=hppa-linux-gcc $ROOT/source/glibc/configure \
--prefix=$DEST --build=$MACH \
--host=hppa-linux --target=hppa-linux \
--with-headers=$ROOT/source/linux/include --disable-profile \
--without-cvs --enable-add-ons
make MAKE="make -j 10" user-defined-trusted-dirs=/lib make install user-defined-trusted-dirs=/lib \
install_root=/tmp/glibc

Christoph mentions that a 'make install' has to be made first, but obviously I can't do that.

If you have a better suggestion, I'll be glad to read it.

PS. I've tried this already, re-configuring it with a new prefix, without cleaning the tree, and copying it into the nfsroot. The boot stops when 'init' is started :(
I'm rebuilding from scratch now, we'll see.

--
Rafael

This looks OK (though providing HOSTCC shouldn't be necessary) and --build, --host, and --target have no effect. The configure script will pick up all it has to know from the CC value.

Providing make isn't necessary. Also, the `user-defined-trusted-dirs' is not needed. Just run

make -j10

Again, loose the `user-defined-trusted-dirs'. Also, is /tmp/glibc where the nfsroot is picked up? If not, just install in the nfsroot directory.

---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

My last build hangs at init.

If I drop --build, --host, and --target I get compilation errors, only HOSTCC was unnecessary.

dropped

compiling now.

No, it's an empty directory. I'm building in a remote machine, which is much faster than this box. I tar the whole thing, ftp it and then unpack it on top of the nfs root. We'll see, it'll take a few minutes.

By the way, I don't intend to use this build for cross compile other packages, I just want to be able to install these in the nfs root. I build the cross compile version with a --prefix that puts it out of the way.

     Rafael

I use

/src/parisc/glibc/configure --prefix=/usr --build=i686-linux \
--host=hppa-linux --with-headers=/usr/tmp/build/linux/include \
--without-cvs --enable-add-ons

make install_root=/tftpboot/<machine_name> install

To add some "light" here in the discussion.

The `user-defined-trusted-dirs=/lib' is exactly the "key" in the discussion. It tells the online running library loader (file ./elf/ld-load.c)
where to search the libraries.

When building a cross tool chain and having the library install in /usr/parisc/hppa-linux/lib, then the cross tool chain will search there, but also the running programs, because this path is hard-coded in the ld-load.c loader executable.

No my idea was, to give a "second search path" for the loader. So the loader will search in /usr/parisc/hppa-linux/lib, will fail and retry in /lib (as defined in `user-defined-trusted-dirs=/lib'). So also the running binary on the target machine will access the glibc in /lib.

With friendly regards
Christoph P.

PS: Of course the way of using --prefix=/usr and installing with install_root != /usr is a way, but lets say it, it is a HACK !!

The problems I have with many tools, is that they are not prepared for cross-compiling very well. I need some evenings for bigger packages.

-------------------------------------------------------------------------
private:	[email protected]
company:	[email protected]

Hi Ulrich,
The "strange" build instructions come from people trying to use glibc
built for a cross-compiling environment, in a native environment too.

Perhaps I'm at fault for mentioning such a thing was possible (by installing then setting up symbolic links so that glibc effectively appears at both it's normal native location and also at the --prefix location). To atone, I think I'll write up a recipe for cross-building native tools and glibc.

Oh, and for the benefit of the list, Ulrich is talking about native builds. This ought to be obvious, but _DO NOT_ build glibc for a cross-compiling environment with --prefix=/usr. If you install it, you'll blow away your system libs. hppa-linux libraries tend to not run very well on x86.

Alan

Linuxcare.  Support for the Revolution.

I've done this more often myself than all the people here together and never did something like this.

Of course you do. If the library is later used in /usr you have to do this. Don't put words in my mouth I didn't say.

No, you're not. This is what the install_root variable is for. If you want to be sure you are not doing something stupid don't run `make install' as root, simply make the directories below that pointed to by install_root writable for yourself.

---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

I think you misunderstand. When I said above about building glibc for a cross compiling environment, I'm talking about building an hppa-linux glibc to be installed on an i686-linux system for use by the cross tools. If binutils and gcc are built with --build=i686-linux --host=i686-linux --target=hppa-linux --prefix=/usr, then it's correct to build glibc with --build=i686-linux --host=hppa-linux --prefix=/usr/hppa-linux because then "make install" will put glibc in the correct place for the cross tools.

Building glibc with --prefix=/usr then "make install_root=/usr/hppa-linux" doesn't put glibc in directories searched by the cross tools.

Alan Modra

Linuxcare.  Support for the Revolution.

Then how comes people install these binaries? And even if not installing, you possibly link against libc.a and get completely wrong code. This is not how you do it.

Then add the appropriate -L and -I.

---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------