Re: Handling object name conflicts

[Ralf Wildenhues]

Hi,

* Chen-Mou Cheng wrote on Fri, May 20, 2005 at 06:29:28AM CEST:
> On 5/19/05, Peter O'Gorman <address@hidden> wrote:
> > Chen-Mou Cheng wrote:
> > |
> > | I have noticed that from 1.5.14 to 1.5.16, the way of handling object
> > | name conflicts has been changed from renaming conflicting files to
> > | just exiting with an ERROR (see the relevant diff fragment attached
> > | below).  I am having problems with 1.5.16 in building gnuradio; it
> > | breaks when gnuradio is trying to link against libfft3w, which
> > | contains objects of same names.  But when I go back to 1.5.14, it
> > | builds successfully.  Can somebody explain to me whether this is
> > | gnuradio/libfft3w's fault, or it is simply a libtool-1.5.16's bug?
> > | Thanks!
> > 
> > This change should only have affected convenience libraries. Is libfft3w a
> > gnuradio convenience library? If so you should rebuild it. There is new code
> > when making a convenience library that ensures there are no duplicated
> > member names.
> 
> Thanks for the prompt response.  I am not sure what you mean by a
> convenience library; libfft3w is a separate project from gnuradio (and
> they are installed separately).  However when building gnuradio, the
> static library /usr/local/lib/libfft3w.a is first extracted in a .lib
> directory under gnuradio's source tree.  Then the object files are
> linked against libgnuradio; it is in this process the new libtool
> breaks.

Please show the libtool link line and all output it generates (copy
and paste).  Please also show the relevant Makefile.am snippet that
describes the library you link, if any.  This way, it might be possible
to decide whether this is a libtool bug or not.

BTW, you meant libfftw3, not libfft3w, right?  The former is not a
library FFTW generates, AFAIK.

Regards,
Ralf