[Top][All Lists]

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

Re: Handling object name conflicts

From: Chen-Mou Cheng
Subject: Re: Handling object name conflicts
Date: Fri, 20 May 2005 00:29:28 -0400

On 5/19/05, Peter O'Gorman <address@hidden> wrote:
> Hash: SHA1
> Chen-Mou Cheng wrote:
> | Hi,
> |
> | 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.
> Peter
> - --
> Peter O'Gorman - http://www.pogma.com
> Version: GnuPG v1.4.0 (Darwin)
> QQ7UxOqxO3P5oMxPrJgvtColpScVHZ6lvsu5Jw2YVz0KkO+SWcAGkKrVBg6w58ZB
> MQNt5X1HvryqWD4NIdI61mrvtQ0J4QBnNqUlITrgaXjZ/z9/+1GbAs85zpBuvOrj
> bRq0jUJ61n0=
> =BJl0

Hi Peter,

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.  Are you saying that this build process is no longer supported
by libtool, and that gnuradio should use this "new code" instead of


reply via email to

[Prev in Thread] Current Thread [Next in Thread]