headers
Wichmann, Mats D | 4 Feb 2004 02:50
Picon
Favicon

RE: [Lsb-build] Need an lsb chroot build environment with real libsinstead of stubs.


> I'd like to set up an LSB chroot build environment for all my 
> packages. 
> There's a slight problem with the lsbdev-chroot solution.  In 
> my RPM build, 
> I compile a tool, then execute the tool within the RPM build. 
>  Since lsbdev-chroot
> only gives me access to stub libraries.  I can't execute the tool.  
> 
> It seems to me that what I need is LSB-si + build tools.  
> This way I would have 
> real libraries instead of stubs, so I can execute my newly 
> compiled tool within
> the RPM build. 
> 
> I can take LSB-si and lsbdev-chroot and start to build such 
> an environment. 
> I'm sending this email to see if anyone else has already done 
> this and can give me some advice. 

There's some work afoot to add build tools to the lsbsi.
I've added the lsb-impl list to this thread for that reason.

Is there a good reason why the alternative build toolkit
(lsbcc) doesn't work for you?  It was designed for the
situation where more tools are needed than are provided
by the chroot, in particulat the GNU-configure type
arrangement where lots of things that aren't part of the
LSB need to run before the build can actually proceed.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bart Whiteley | 4 Feb 2004 04:16
Picon
Favicon

Re: [Lsb-build] Need an lsb chroot build environment with real libsinstead of stubs.

On Tuesday 03 February 2004 06:50 pm, Wichmann, Mats D wrote:
> > I'd like to set up an LSB chroot build environment for all my
> > packages.
> > There's a slight problem with the lsbdev-chroot solution.  In
> > my RPM build,
> > I compile a tool, then execute the tool within the RPM build.
> >  Since lsbdev-chroot
> > only gives me access to stub libraries.  I can't execute the tool.
> >
> > It seems to me that what I need is LSB-si + build tools.
> > This way I would have
> > real libraries instead of stubs, so I can execute my newly
> > compiled tool within
> > the RPM build.
> >
> > I can take LSB-si and lsbdev-chroot and start to build such
> > an environment.
> > I'm sending this email to see if anyone else has already done
> > this and can give me some advice.
>
> There's some work afoot to add build tools to the lsbsi.
> I've added the lsb-impl list to this thread for that reason.
>
> Is there a good reason why the alternative build toolkit
> (lsbcc) doesn't work for you?

I'd prefer to use chroot.  I like to set up a build environment that
is NFS exported read-only.  I usually set this up by installing a distro
with a devel installation profile, then rsyncing the whole thing
to a directory on a NFS server.  Users can then NFS mount this,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Fent | 4 Feb 2004 10:26
Picon

amd64

Hi,

I'm actually working on getting the implementation 
running on AMD64.

The first problem was a missing -D_GNU_SOURCE in the 
binutils/intl/Makefile.in, which led to a segfault calling 'as'.

Here is a patch for binutils in phase2:

--- intl/Makefile.in.ORG        2004-02-03 14:23:48.000000000 +0100
+++ intl/Makefile.in    2004-02-03 14:24:12.000000000 +0100
 <at>  <at>  -79,7 +79,7  <at>  <at> 
 .c.lo:
        $(LIBTOOL) --mode=compile $(COMPILE) $<

-INCLUDES = -I. -I$(srcdir)
+INCLUDES = -I. -I$(srcdir) -D_GNU_SOURCE

 all: all- <at> USE_INCLUDED_LIBINTL <at> 

This is when using gettext from binutils, not from glibc.

Is there a special reason for not using the glibc gettext functions?

Stefan
--

-- 
Stefan Fent 
SuSE Linux AG, Maxfeldstr. 5, D-90409 Nuernberg
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Fent | 4 Feb 2004 15:34
Picon

Re: amd64

* Wichmann, Mats D <mats.d.wichmann <at> intel.com> [040204 14:37]:
> 
> > I'm actually working on getting the implementation 
> > running on AMD64.
> 
> Super!
> 
> > The first problem was a missing -D_GNU_SOURCE in the 
> > binutils/intl/Makefile.in, which led to a segfault calling 'as'.
> > 
> > Here is a patch for binutils in phase2:
> > 
> > --- intl/Makefile.in.ORG        2004-02-03 14:23:48.000000000 +0100
> > +++ intl/Makefile.in    2004-02-03 14:24:12.000000000 +0100
> >  <at>  <at>  -79,7 +79,7  <at>  <at> 
> >  .c.lo:
> >         $(LIBTOOL) --mode=compile $(COMPILE) $<
> >  
> > -INCLUDES = -I. -I$(srcdir)
> > +INCLUDES = -I. -I$(srcdir) -D_GNU_SOURCE
> >  
> >  all: all- <at> USE_INCLUDED_LIBINTL <at> 
> 
> This isn't hard to apply.
>  
> > This is when using gettext from binutils, not from glibc.
> > 
> > Is there a special reason for not using the glibc gettext functions?
> 
> Not consciously on our part. In fact, I wasn't aware
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wichmann, Mats D | 4 Feb 2004 15:56
Picon
Favicon

RE: amd64


> > > This is when using gettext from binutils, not from glibc.
> > > 
> > > Is there a special reason for not using the glibc gettext
functions?
> > 
...
> > We're not configuring binutils with --with-included-gettext.
> > Is it possible the binutils configure script is not
> > detecting that the just-built phase2 glibc actually
> > has gettext support?
> > 
> 
> No, it is detected:
> 
> [...]
> -: checking for LC_MESSAGES... yes
> -: checking whether NLS is requested... yes
> -: checking whether included gettext is requested... no
> -: checking for libintl.h... yes
> -: checking for gettext in libc... yes
> -: checking for msgfmt... no
> -: checking for msgfmt... (cached) no
> -: checking for gmsgfmt... no
> -: checking for xgettext... :
> [...]

So then...

How did we get to the situation you reported, where
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stefan Fent | 4 Feb 2004 16:01
Picon

Re: amd64

* Wichmann, Mats D <mats.d.wichmann <at> intel.com> [040204 15:56]:
> 
> > > > This is when using gettext from binutils, not from glibc.
> > > > 
> > > > Is there a special reason for not using the glibc gettext
> functions?
> > > 
> ...
> > > We're not configuring binutils with --with-included-gettext.
> > > Is it possible the binutils configure script is not
> > > detecting that the just-built phase2 glibc actually
> > > has gettext support?
> > > 
> > 
> > No, it is detected:
> > 
> > [...]
> > -: checking for LC_MESSAGES... yes
> > -: checking whether NLS is requested... yes
> > -: checking whether included gettext is requested... no
> > -: checking for libintl.h... yes
> > -: checking for gettext in libc... yes
> > -: checking for msgfmt... no
> > -: checking for msgfmt... (cached) no
> > -: checking for gmsgfmt... no
> > -: checking for xgettext... :
> > [...]
> 
> So then...
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wichmann, Mats D | 4 Feb 2004 16:30
Picon
Favicon

RE: amd64


> I'm just trying to find out..
> I'm a little confused  by this anyways, it should segfault on 
> Itanium as well, did anybody test that?

Yes.  The Itanium build doesn't fail in the same
way, but it does fail mysteriously.  The step after
binutils in phase2 is gcc, then coreutils.  The
gcc build completes, then the coreutils construction
fails during the configure phase, thus:

checking for GNU gettext in libc... yes
configure: creating ./config.status
malloc: make_cmd.c:89: assertion botched
malloc: block on free list clobbered
Stopping myself...
E: Child(362) killed by signal 6.

So something is very sick there, too.
Permalink | Reply | 0 comments |
headers
Bart Whiteley | 5 Feb 2004 00:33
Picon
Favicon

Re: [Lsb-build] Need an lsb chroot build environment with real libs instead of stubs.

I've started to create a "jail" build environment that is lsbsi + build tools. 

I started with this: 
ftp://ftp.freestandards.org/pub/lsb/impl/released/binary/ia32/lsbsi-ia32-1.3.1.tar.bz2
I extracted it to /opt/lsbsi-1.3.1.

I can chroot into that environment and run simple commands. 
Next I got gcc from here: 
ftp://ftp.freestandards.org/pub/lsb/impl/packages/gcc-core-3.3.2.tar.bz2

I built this on my SuSE9 host system as per the instructions for building/installing gcc.  
I configured with --prefix=/opt/gcctmp.  I installed with 'make DESTDIR=/opt/lsbsi-1.3.1 install' 

Observe: 

# /opt/lsbsi-1.3.1/opt/gcctmp/bin/gcc --version
gcc (GCC) 3.3.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# chroot /opt/lsbsi-1.3.1/
bash-2.05b# ls /opt/gcctmp/bin/gcc
/opt/gcctmp/bin/gcc
bash-2.05b# /opt/gcctmp/bin/gcc --version
bash: /opt/gcctmp/bin/gcc: No such file or directory
bash-2.05b# ldd /opt/gcctmp/bin/gcc
/usr/bin/ldd: line 1: /opt/gcctmp/bin/gcc: No such file or directory

Any idea what's going on here?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christopher Yeoh | 5 Feb 2004 01:23
Picon
Favicon

Re: Re: [Lsb-build] Need an lsb chroot build environment with real libs instead of stubs.

At 2004/2/4 16:33-0700  Bart Whiteley writes:
> I did notice this: 
> 
> # ldd /opt/lsbsi-1.3.1/opt/gcctmp/bin/gcc
>         libc.so.6 => /lib/i686/libc.so.6 (0x40028000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> # ls /opt/lsbsi-1.3.1/lib/ld-linux*
> /bin/ls: /opt/lsbsi-1.3.1/lib/ld-linux*: No such file or directory
> 
> So there's no ld-linux.so.2 in lsbsi.  Could this be the problem? 
> How do I get around this? 

That is the problem. Its caused by trying to run a non lsb compliant
binary (gcc) in the si. You can most likely work around it by creating
a symlink from /lib/ld-linux.so.2 (standard runtime linux linker) to
/lib/ld-lsb.so.1 (LSB runtime linker).

Note that when it comes to testing the application you have built in
the SI, you'll want to remove that link before doing so, as the LSB
compliant binaries should use the LSB runtime linker.

Chris
--

-- 
cyeoh <at> au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia
Permalink | Reply | 0 comments |
headers
Wichmann, Mats D | 5 Feb 2004 01:30
Picon
Favicon

RE: [Lsb-build] Need an lsb chroot build environment with real libsinstead of stubs.


> Observe: 
> 
> # /opt/lsbsi-1.3.1/opt/gcctmp/bin/gcc --version
> gcc (GCC) 3.3.2
> Copyright (C) 2003 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. 
>  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A 
> PARTICULAR PURPOSE.
> 
> # chroot /opt/lsbsi-1.3.1/
> bash-2.05b# ls /opt/gcctmp/bin/gcc
> /opt/gcctmp/bin/gcc
> bash-2.05b# /opt/gcctmp/bin/gcc --version
> bash: /opt/gcctmp/bin/gcc: No such file or directory
> bash-2.05b# ldd /opt/gcctmp/bin/gcc
> /usr/bin/ldd: line 1: /opt/gcctmp/bin/gcc: No such file or directory
> 
> Any idea what's going on here? 
> 
> I did notice this: 
> 
> # ldd /opt/lsbsi-1.3.1/opt/gcctmp/bin/gcc
>         libc.so.6 => /lib/i686/libc.so.6 (0x40028000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> # ls /opt/lsbsi-1.3.1/lib/ld-linux*
> /bin/ls: /opt/lsbsi-1.3.1/lib/ld-linux*: No such file or directory
> 
> So there's no ld-linux.so.2 in lsbsi.
(Continue reading)

Permalink | Reply | 4 comments |

Gmane