[Buildroot] staging_dir/usr/lib vs staging_dir/lib

[Buildroot] staging_dir/usr/lib vs staging_dir/lib

[Christopher Reder]

It seems like there may be some confusion over what directories to use when
installing/hosting/storing libs.

 

I just pulled down the latest and enabled fbv which selected libungif.  In
doing so, it fails when it tries to remove libs from staging_dir/lib because
the libs are actually in staging_dir/usr/lib.  

 

Where should those libs be?  Are they being installed in the wrong directory
or are they trying to remove them from the wrong directory?

 

Can someone clarify this?  Same thing happened when trying to build libpng
as well when it was trying to cp libs over and it was copying from a
directory where they were not installed.

 

TIA

 

make[3]: Leaving directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4/util'

make[2]: Leaving directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4/util'

Making install in doc

make[2]: Entering directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4/doc'

make[3]: Entering directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4/doc'

make[3]: Nothing to be done for `install-exec-am'.

make[3]: Nothing to be done for `install-data-am'.

make[3]: Leaving directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4/doc'

make[2]: Leaving directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4/doc'

Making install in pic

make[2]: Entering directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4/pic'

make[3]: Entering directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4/pic'

make[3]: Nothing to be done for `install-exec-am'.

make[3]: Nothing to be done for `install-data-am'.

make[3]: Leaving directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4/pic'

make[2]: Leaving directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4/pic'

make[2]: Entering directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4'

make[3]: Entering directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4'

make[3]: Nothing to be done for `install-exec-am'.

make[3]: Nothing to be done for `install-data-am'.

make[3]: Leaving directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4'

make[2]: Leaving directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4'

make[1]: Leaving directory
`/home/christopher/svn_buildroot/buildroot/build_arm/libungif-4.1.4'

rm
/home/christopher/svn_buildroot/buildroot/build_arm/staging_dir/lib/libungif
.la

rm: cannot remove
`/home/christopher/svn_buildroot/buildroot/build_arm/staging_dir/lib/libungi
f.la': No such file or directory

make: ***
[/home/christopher/svn_buildroot/buildroot/build_arm/staging_dir/lib/libungi
f.a] Error 1

linuxbox:/home/christopher/svn_buildroot/buildroot#

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20070731/579cd6ff/attachment-0001.htm 

[Buildroot] staging_dir/usr/lib vs staging_dir/lib

[Hans-Christian Egtvedt]

On Tue, 2007-07-31 at 13:38 -0500, Christopher Reder wrote:
> It seems like there may be some confusion over what directories to use
> when installing/hosting/storing libs.

Probably my bad (-:

> I just pulled down the latest and enabled fbv which selected libungif.
> In doing so, it fails when it tries to remove libs from
> staging_dir/lib because the libs are actually in
> staging_dir/usr/lib.  

Weird, because staging_dir/usr is a symlink to staging_dir/.

> Where should those libs be?  Are they being installed in the wrong
> directory or are they trying to remove them from the wrong directory?

Normal libs should (IMHO) be in /usr/lib.

> Can someone clarify this?  Same thing happened when trying to build
> libpng as well when it was trying to cp libs over and it was copying
> from a directory where they were not installed.

I will have a look at libungif, libpng and fbv to see if anything is
wrong. IIRC fbv was my first try at adding a package to buildroot, it
could have used some reviewing.

-- 
With kind regards,
Hans-Christian Egtvedt

[Buildroot] [PATCH] staging_dir/usr/lib vs staging_dir/lib

[Hans-Christian Egtvedt]

On Wed, 2007-08-01 at 07:59 +0200, Hans-Christian Egtvedt wrote:
> On Tue, 2007-07-31 at 13:38 -0500, Christopher Reder wrote:
> > It seems like there may be some confusion over what directories to use
> > when installing/hosting/storing libs.
> 
> Probably my bad (-:

I cleaned up libpng, libungif and fbv. Although my upstream snapshot is
some days old.

> > I just pulled down the latest and enabled fbv which selected libungif.
> > In doing so, it fails when it tries to remove libs from
> > staging_dir/lib because the libs are actually in
> > staging_dir/usr/lib.  
> 
> Weird, because staging_dir/usr is a symlink to staging_dir/.

Actually, removing libungif.la is not something that should have been
done when installing (I think, anybody know the reason?). I have
replaced it with a SED fixing the libdir in the included patch.

<snipp>

-- 
With kind regards,
Hans-Christian Egtvedt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: br2-clean-libpng-libungif-and-fbv.patch
Type: text/x-patch
Size: 3855 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20070801/5be1e4ce/attachment.bin 

[Buildroot] staging_dir/usr/lib vs staging_dir/lib

[Bernhard Fischer]

On Wed, Aug 01, 2007 at 07:59:56AM +0200, Hans-Christian Egtvedt wrote:

>Weird, because staging_dir/usr is a symlink to staging_dir/.

This means that you don't use a toolchain that supports sysroot.

For non-sysroot enabled toolchains we currently symlink staging_dir/usr
to staging_dir because the old, deprecated gcc had quite some trouble
otherwise and i don't care to fix them up (since the current stable
series of gcc work fine for me).

Please note that i, personally didn't enable sysroot support for 4.0.x
 but skhill did (IIRC) so you're better off to use 4.2.1 for this.