On Tuesday 05 June 2007, David McCullough wrote: > Jivin Mike Frysinger lays it down ... > > > 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 > > Quite the contrary. > > The include/Makefile and lib/Makefile impose a very specific order, and > those files have complete control, which IMO gives you more control > over what happens than letting the packages install into a common > staging directory as they please. > > The existing mechanism is a top-bottom, first to install the header > wins approach, and this means you can be sure which "xyz.h" is > installed into the lib/include directory, even if two packages have the > same file they wish to install. "config.h" and the like have already be > dealt with in this way.
we're talking about different things ... you're referring to order compiled (which is handled as you've outlined), i'm referring to the order given to the compiler ... in other words, whether the -I/-L <staging header path> appears that the beginning, middle, or end of the actual compiler command ... it can make a difference with some applications and it seems that it hasnt really come up the current uClinux-dist since nothing has broken -mike
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
