Hi guys:
Thanks for you feedback and insight.
I have done some reading and in general, ppc64 should be regarded as
having 32-bit userspace, which is different from x86_64 which has
64-bit userspace.
With that in mind, I believe that make.d/boel_binaries.rul should be
modified to reflect this. With the following patch, the boel_binaries
created work fine under ppc64 (libc.so.6 in boel_binaries is 32-bit as
opposed to 64-bit):
Index: boel_binaries.inc
===================================================================
--- boel_binaries.inc (revision 4079)
+++ boel_binaries.inc (working copy)
@@ -81,7 +81,6 @@
cd $(BOEL_BINARIES_DIR)/sbin && $(foreach binary,$(shell cat
$(SRC_DIR)/$(LVM_DIR)/tools/.commands),ln -s -f lvm $(binary) && )
/bin/true
mkdir -m 755 -p $(BOEL_BINARIES_DIR)/lib
- test ! -d /lib64 || mkdir -m 755 -p $(BOEL_BINARIES_DIR)/lib64
#
ifdef WITH_CTCS
@@ -117,6 +116,7 @@
#XXX simplifying the code. let's see if anything breaks. -BEF-
output=`find /lib/ -name libnss_dns*`
test ! -n "$(output)" || cp -a /lib/libnss_dns*
$(BOEL_BINARIES_DIR)/lib
+ mkdir -m 755 -p $(BOEL_BINARIES_DIR)/lib64
test ! -d /lib64 || cp -a /lib64/libnss_dns* $(BOEL_BINARIES_DIR)/lib64
endif
@@ -125,7 +125,7 @@
# any soft links. Note: This does not require PIC libraries -- it will
# copy standard libraries if it can't find a PIC equivalent. -BEF-
#
-ifneq ($(ARCH),i386)
+ifeq ($(USERSPACE64),1)
# But copy over ld.so* files first. for some reason these don't always
# get copied by mklibs if both /lib/ld* and /lib64/ld* exist) -BEF-
#
@@ -134,10 +134,13 @@
test ! -d /lib64 || cp -a /lib64/ld* $(BOEL_BINARIES_DIR)/lib64
endif
- TGTLIBDIR=lib ; \
- test ! -d /lib64 || TGTLIBDIR=lib64 ; \
+ifeq ($(USERSPACE64),1)
cd $(BOEL_BINARIES_DIR) \
- && $(PYTHON) $(TOPDIR)/initrd_source/mklibs -L
$(SRC_DIR)/$(PARTED_DIR)/libparted/.libs:$(DISCOVER_DIR)/lib/.libs:$(SRC_DIR)/$(DEVMAPPER_DIR)/lib/ioctl:$(SRC_DIR)/$(E2FSPROGS_DIR)/lib:/lib64:/usr/
lib64:/usr/kerberos/lib64:/lib:/usr/lib:/usr/kerberos/lib:/usr/local/lib:/opt/gnome/lib:/lib/tls:`find
/lib/tls /usr/lib/tls /lib64/tls /usr/lib64/tls -type d 2>/dev/null |
tr '\n' :` -v -d $$TGTLIBDIR bin/* sbin
/* usr/bin/* usr/sbin/* $(INITRD_BUILD_DIR)/*bin/*
$(INITRD_BUILD_DIR)/usr/*bin/*
+ && $(PYTHON) $(TOPDIR)/initrd_source/mklibs -L
$(SRC_DIR)/$(PARTED_DIR)/libparted/.libs:$(DISCOVER_DIR)/lib/.libs:$(SRC_DIR)/$(DEVMAPPER_DIR)/lib/ioctl:$(SRC_DIR)/$(E2FSPROGS_DIR)/lib:/lib64:/usr/
lib64:/usr/kerberos/lib64:/lib:/usr/lib:/usr/kerberos/lib:/usr/local/lib:/opt/gnome/lib:/lib/tls:`find
/lib/tls /usr/lib/tls /lib64/tls /usr/lib64/tls -type d 2>/dev/null |
tr '\n' :` -v -d lib64 bin/* sbin/* usr
/bin/* usr/sbin/* $(INITRD_BUILD_DIR)/*bin/* $(INITRD_BUILD_DIR)/usr/*bin/*
+else
+ cd $(BOEL_BINARIES_DIR) \
+ && $(PYTHON) $(TOPDIR)/initrd_source/mklibs -L
$(SRC_DIR)/$(PARTED_DIR)/libparted/.libs:$(DISCOVER_DIR)/lib/.libs:$(SRC_DIR)/$(DEVMAPPER_DIR)/lib/ioctl:$(SRC_DIR)/$(E2FSPROGS_DIR)/lib:/lib:/usr/li
b:/usr/kerberos/lib:/usr/local/lib:/opt/gnome/lib:/lib/tls:`find
/lib/tls /usr/lib/tls -type d 2>/dev/null | tr '\n' :` -v -d lib bin/*
sbin/* usr/bin/* usr/sbin/* $(INITRD_BUILD_DIR)/*bin/*
$(INITRD_BUILD_DIR)/u
sr/*bin/*
+endif
ifdef IS_PPC64
# Copy all the libnss*. It seems that with ppc64 these are not
The major change is that unless the system is USERSPACE64 (x86_64,
ia64), mklibs should not traverse through any lib64 directories --
this fixes the issue with ppc64 which is USERSPACE32.
I could probably do a quick build test on x86 but if someone can test
this on x86_64, that would be great.
Thanks,
Bernard
On 6/4/07, Sean Dague <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 04, 2007 at 12:29:21PM +0200, Andrea Righi wrote:
> > Bernard Li wrote:
> > > Currently the issue I am facing is that the gcc which came with the
> > > ppc64 system would some times build 32-bit binaries/libraries and some
> > > times build 64-bit binaries/libraries. Things like parted, are
> > > compiled 32-bit but libc.so.6 ended up being 64-bit so when my
> > > boel_binaries.tar.gz was retrieved, I would get the ELFCLASS error
> > > (the gcc which came with my system is 32-bit even though my OS is
> > > 64-bit).
> > >
> > > Actually this may be an issue with the mklibs script in initrd_source
> > > -- I'm not sure. Not sure if updating the mklibs script would help in
> > > this case, but currently we cannot update it to the latest version
> > > since it requires building. We also have some local modifications to
> > > the script itself.
> >
> > Another way could be to run mklibs in 2 steps (for 64-bit archs):
> > 1 - find the 64-bit binaries (grepping for example the output of ldd and
> > checking if there's a /lib64/), run mklibs only for this binaries and put
> > the
> > libraries in /lib64 (into the initrd and boel_binaries)
> > 2 - find the 32-bit binaires in the same way and put the libraries in /lib
> > (in
> > initrd and boel_binaries)
> >
> > Anyway, the best approach would be to build *only* 64-bit binaries in 64-bit
> > architectures...
>
> On a Power system it is typical to have userspace 32bit. Unlike x86,
> Power has access to the same number of general purpose registers in
> 32bit mode as 64bit (in x86_64 you get 8 more in 64bit mode), so 64bit
> is just slower (by effectively 1/2ing you cache lines). If you don't
> need > 4GB memory, staying with 32bit binary is probably the way to go.
>
> > > Right now I got things working by manually hacking the
> > > boel_binaries.tar.gz (much like how Jing Sun described in his post:
> > > http://www.mail-archive.com/[email protected]/msg02530.html),
> > > but it would be nice if we can get SystemImager to do the right
> > > thing.
>
> My guess is that mklibs is doing it, based on the output of uname. I
> know the gentoo guys have a script for faking uname for a chroot from 64
> -> 32bit mode. That might be all you need to wedge in here to get
> things to come out the way you want.
>
> -Sean
>
> --
> __________________________________________________________________
>
> Sean Dague Mid-Hudson Valley
> sean at dague dot net Linux Users Group
> http://dague.net http://mhvlug.org
>
> There is no silver bullet. Plus, werewolves make better neighbors
> than zombies, and they tend to keep the vampire population down.
> __________________________________________________________________
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
sisuite-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
