[uClibc] libtool problem

[Ned Ludd]

On Thu, 2004-10-07 at 13:59, Sander Knopper wrote:
> Ok, thankx!
> 
> So I'd better just drop it?

Your options are.
1) drop it
2) patch xfsprogs using _syscall3()
3) patch uClibc and submit a patch to this list.

>  What about jfsutils?

It compiles fine. However jffs2 is probably ideal if your looking for an
embedded aware journalling file system.  http://sources.redhat.com/jffs2

When jffs2 is used in tandem with squashfs it can make for a really
sweet failsafe setup. Check out how the OpenWrt project does it.
http://openwrt.org




> Sander
> 
> P.S. Some time ago I sent some patches for coreutils and bison (and now I 
> looked after some other apps they turned out to be outdated as well) but I 
> got no reply to that and neither of them has been applied. They were both for 
> the buildroot scripts. Are you guys using some old versions on purpose 
> because they won't work else?

buildroot is not that actively maintained on purpose. 
From what I gather as useful as it is in a pinch Erik and Manuel want
the embedded community to grow up a little and rely a little less on
uclibc-buildroot so they can focus on the uClibc core itself.


> Anyway, I tried them myself and the newest 
> versions of bison and coreutils work great on a i386 based system.
> 
> 
> Op donderdag 7 oktober 2004 19:01, schreef Ned Ludd:
> > On Thu, 2004-10-07 at 09:42, Sander Knopper wrote:
> > > Hi all,
> > >
> > > I just tried to compile xfsprogs with my newly built buildroot and it
> > > gave me a libtool related error. First of all it complained about some
> > > errors in /usr/bin/libtool itself. When I took a look I saw that there
> > > were a lot of variabled declared regarding to paths used in the buildroot
> > > building proces which aren't valid anymore at the moment you chroot into
> > > you buildroot.
> > >
> > > After fixing all the paths in there I tried again and it then gave me
> > > this error:
> > >
> > > /usr/bin/libtool --mode=compile gcc -O1 -g -DNDEBUG -funsigned-char -Wall
> > > -I../include -DVERSION=\"2.6.13\" -DLOCALEDIR=\"/usr/share/locale\"
> > > -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I. 
> > > -D_REENTRANT -fno-strict-aliasing -c bit.c
> > > libtool: compile: unable to infer tagged configuration
> > > libtool: compile: specify a tag with `--tag'
> > > make[1]: *** [bit.lo] Error 1
> > > make: *** [default] Error 2
> >
> > After you get past all that your going to run into a small problem with
> > mincore() while trying to compile said program.
> >
> > uClibc does not seem to support this syscall as of yet.
> > You could probably work around it by using _syscall3() in the xfsprogs
> > but as of right now it's on the list of "wont compile with uClibc" till
> > such a time as mincore() support is added (if ever).
> > The mincore() system call itself does not appear to be part of POSIX or
> > the Single Unix Specification so that's perhaps why it's never been
> > implemented. See the manpage for more info.
> >
> > > I searched with google and found out you have to specify --tag in these
> > > kind of situations. But I was just wondering if these two things are
> > > related.
> > >
> > >
> > > Sander Knopper
> > >
> > > ______________________________________________________________________
> > > _______________________________________________
> > > uClibc mailing list
> > > uClibc at uclibc.org
> > > http://uclibc.org/mailman/listinfo/uclibc
> 
> ______________________________________________________________________
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://uclibc.org/mailman/listinfo/uclibc
-- 
Ned Ludd <solar at gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20041007/e2de83cf/attachment-0002.pgp