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 ;-).
Cheers,
Davidm
--
David McCullough, [EMAIL PROTECTED], Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
_______________________________________________
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
