[Flac-dev] Compiling static libFLAC.a still requires libogg.dylib
glenn.mccord at gmail.com
Tue Aug 17 15:18:57 PDT 2010
On Wed, Aug 18, 2010 at 9:51 AM, Richard Ash <richard at audacityteam.org> wrote:
> On Tue, 2010-08-17 at 15:09 +1200, Glenn McCord wrote:
>> When I do that, the error looks like
>> libtool: link: gcc -I/Users/glennm/libOGG-i386/include -O3
>> -funroll-loops -finline-functions -Wall -W -Winline -arch i386 -arch
>> i386 -o flac analyze.o decode.o encode.o foreign_metadata.o main.o
>> local_string_utils.o utils.o vorbiscomment.o
>> ../../src/share/utf8/.libs/libutf8.a ../../src/libFLAC/.libs/libFLAC.a
>> /Users/glennm/libOGG-i386/lib/libogg.dylib -liconv -lm
>> /Users/glennm/libOGG-i386/lib/libogg.dylib: No such file or directory
>> Could this be something to do with the way libtool has been set up?
> Have you re-run configure since removing the dynamic libraries? If not,
> then the old libtool setup will certainly still be being applied.
Yes. After deleting libogg.dylib I do a make distclean, then rerun
configure. Configure seems to work fine although there are two lines
checking if g++ static flag -static works... no
checking whether the g++ linker
(/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld) supports shared
Running make will then give the libtool link error.
> It's worth pointing out that this is the link command compiling the
> "flac" command-line tool, and by this point the static libFLAC.a has has
> already been compiled. So your options have had an effect, just not
> quite the full one you need.
> I suspect that the presence of library file names (rather than just -l
> options) in the libtool gcc command line is evidence of libtool not
> being used quite the way it's authors intended, but I'm no expert in
> Richard Ash
More information about the Flac-dev