On Mon, 2005-07-25 at 03:48 -0500, Peter Samuelson wrote: > Oh, I didn't mean to imply you couldn't have more than one of these > libraries. Same as you're planning to perhaps have more than one > object file. It's really the same thing, but I think it makes life > easier for people doing manual linking to use /usr/lib/libfoo.a rather > than /usr/lib/foo.o or /usr/lib/felix/rtl/foo.o or what have you. The > difference is being able to say "-lfoo" on the link line rather than > having to supply the complete pathname. Good point. > > It might confuse a client using this: > > > > g++ -lrtl mymain.o mycode.o > > > > usually; providing their own 'main()' function in 'mymain.o', > > if they accidently wrote: > > > > g++ -lrtl mycode.o > > That's really stretching it. Yeah, I agree :) Note that 'normally' neither of these points is relevant, because the linkage is all taken care of automatically with a script: the 'normal' client of the system just types in a line like flx myfile or flx --static myfile and all the compilation and linkage is handled automatically. Whilst manual linkage is indeed possible, with the Debian package that feature is not yet advertised/supported. However .. there is an additional advantage to using an archive not an object file: suppose a particular driver (that's the main function) is designed to run a particular kind of client code, and needs additional run time library support -- where would you put it? With the .a archive idea, the answer is obvious. With just a .o object file, you'd need an additional support library (and another entry on the command line). With that extension to your argument, using .a archive is looking like a good idea. Thanks! -- John Skaller <skaller at users dot sourceforge dot net>
Attachment:
signature.asc
Description: This is a digitally signed message part