On Wednesday 30 May 2007, David McCullough wrote:
> Jivin Mike Frysinger lays it down ...
>
> > as we added support for real shared libraries in our Blackfin dist via
> > FDPIC ELF, we quickly hit limitations due to the way libraries are
> > handled currently.  basically everything is done by symlinking static
> > archives and header files into specific directories and having the rest
> > of the packages look in there.  this works great for something like FLAT,
> > but not for anything else.
>
> Thats not quite correct.  We don't even use FLAT in house and the
> MIPS/MIPS64/SH3/SH4/ARM/X86/Xscale system we use all run a combination
> of shared and static libs without a problem.
>
> > what we've done is introduce a staging directory:
> >  STAGEDIR = $(ROOTDIR)/staging
> > and we've converted our libraries to do `make install
> > DESTDIR=$(STAGEDIR)` so that the headers and libraries and such are all
> > installed properly.  a small sed script is run on the linker scripts
> > (/usr/lib/*.la) and pkg-config scripts (/usr/lib/pkgconfig/*.pc) so that
> > the runtime path (/usr) is kept sep from the build time path
> > ($(STAGEDIR)/usr).  a $(CROSS_COMPILE)-pkg-config script is created in
> > tools/ which autotool configure scripts automatically check for and is
> > written to look in $(STAGEDIR) for its .pc files (so as to not mix with
> > host .pc files).
> >
> > the other advantage here is that we dont have to worry about packages
> > that change their headers from the build directory to the install
> > directory. ncurses is an example of this -- it renames some of its
> > headers as it installs.
> >
> > the last piece of the puzzle requires some toolchain tweaking (this is
> > the crappy part).  CPPFLAGS is augmented with -isystem
> > $(STAGEDIR)/usr/include as -I can cause trouble with package search order
> > -- some packages name headers in their distribution the same as things
> > you'd find in /usr/include. with -isystem, this isnt a problem as the
> > directory is added to the right location in the search order.  the real
> > pain is getting the linker to behave as there is no gcc -lsystem.  adding
> > -L$(STAGEDIR)/usr/lib -L$(STAGEDIR)/lib to LDFLAGS works *most* of the
> > time, but can fail in some instances -- like headers, some packages have
> > local archives named the same as libraries found in the search path and
> > packages may put user $(LDFLAGS) into the wrong order (bash comes to
> > mind).  one solution is to add a small ld wrapper to the dist and insert
> > it into $PATH so that it automatically appends -L and -rpath-link flags
> > to the very end before invoking the real linker.  i'm open to ideas here
> > as i dislike this approach ... too bad it works :/
>
> What we have been doing more and more is something like:
>
>       lib/osip2/makefile
>
> configure the app/lib,  install it within it's build directory,  then
> have include/Makefile lib/Makefile put the files from there as needed
> into lib/include.  No toolchain hacking required so far (your case may
> differ ;-).

so you're pretty much doing what i proposed here but not in a centralized 
manner and not worrying about the order of includes/libraries

instead of installing into the stagedir, you install into a local builddir 
(which i started to do with libraries in Blackfin but found stagedir to be 
nicer), and then symlink everything into lib/ and include/ and 
add -I$(ROOTDIR)/include to CFLAGS and -L$(ROOTDIR)/lib to LDFLAGS

so what i proposed would require minimal changes to uClinux-dist:
 - throw out the painful include/lib symlinking steps
 - change install directory to $(STAGEDIR) rather than $PWD/build/install
 - change linking flags from -L$(ROOTDIR)/lib to -L$(STAGEDIR)/lib
 - change include flags from -I$(ROOTDIR)/include to -I$(STAGEDIR)/usr/include
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Reply via email to