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