tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: libfl.a -> libfl.so?



On Sun, Jan 13, 2013 at 10:42:30AM +0100, Thomas Klausner wrote:
 > > > When linking a shared library with libtool against libfl.a it
 > > > complains:
 > > > 
 > > > *** Warning: linker path does not have real file for library -lfl.
 > > > *** I have the capability to make that library automatically link in when
 > > > *** you link to this library.  But I can only do this if you have a
 > > > *** shared version of the library, which you do not appear to have
 > > > *** because I did check the linker path looking for a file starting
 > > > *** with libfl and none of the candidates passed a file format test
 > > > *** using a regex pattern. Last file checked: /usr/lib/libfl.a
 > > > 
 > > > Is there a reason we don't provide a libfl.so?
 > > 
 > > It is tiny and trivial.
 > 
 > So you agree we should add libfl.so? :)

...no, not really.

 > > My vote would be to make libtool less stupid...
 > 
 > What is your suggestion what it should do (in this case)?
 > I don't think you can assume that .a files are PIC.

Well... in the case of libfl, if it becomes a problem the path of
least resistance is to provide the necessary three lines of code in
the lexer source file instead and drop the -lfl entirely.

(Also, no shared library should be using the default yy* namespace...)

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index