flac dev - Aug 2010 - Compiling static libFLAC.a still requires libogg.dylib

Thanks for the reply. I would very much like OGG container support, so
disabling it isn't really an option. I have built OGG so that it
creates a libogg.a, libogg.0.dylib and a symbolically linked
libogg.dylib (that links to the libogg.0.dylib) file.

If I remove the .dylib files in an attempt to 'encourage' the compiler
to use libogg.a, then it complains that it can't find the .dylib file.

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/grabbag/.libs/libgrabbag.a
../../src/share/getopt/libgetopt.a
../../src/share/replaygain_analysis/.libs/libreplaygain_analysis.a
../../src/share/replaygain_synthesis/.libs/libreplaygain_synthesis.a
../../src/share/utf8/.libs/libutf8.a ../../src/libFLAC/.libs/libFLAC.a
-L/Users/glennm/libOGG-i386/lib
/Users/glennm/libOGG-i386/lib/libogg.dylib -liconv -lm
i686-apple-darwin10-gcc-4.2.1:
/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?






On Tue, Aug 17, 2010 at 2:57 PM, Brian Willoughby <brianw at
sounds.wa.com> wrote:
>
> On Aug 16, 2010, at 16:44, Glenn McCord wrote:
>>
>> Hi, I'm trying to compile a static lib of libFLAC yet whenever I
use
>> it in an application, the application will fail on other machines
>> because it's trying to use libogg.0.dylib.
>>
>> I'm using the following configure command
>>
>> ./configure prefix=${HOME}/libFLAC --disable-asm-optimizations
>> --disable-dependency-tracking --with-ogg=${HOME}/libOGG
>> --enable-shared=no
>>
>> but to do avail. Is there something else that I need to do? I'm on
>> OSX, if that matters.
>
>
> A couple of things,
>
> As long as you link to a .dylib, it won't be completely static. ?The
FLAC
> part might be static, but the OGG part is still going to be dynamic unless
> you rebuild some kind of libogg.a that is also static, first.
>
> There is also a configure/build option, I remember, to build the FLAC
> library without any Ogg support. ?That could be a serious omission, but if
> it works it should remove the libogg.dylib dependency.
>
> I'm also on OSX, having created the installer, but I have not tried to
> divorce FLAC from Ogg. ?When I saw the dependency, I just downloaded Ogg
and
> built it, too. ?In your case, you may have to build Ogg differently, or
> remove it completely, as I mention above.
>
> Brian Willoughby
> Sound Consulting
>
>

On Mon, Aug 16, 2010 at 11:09 PM, Glenn McCord <glenn.mccord at gmail.com>
wrote:
> 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/grabbag/.libs/libgrabbag.a
> ../../src/share/getopt/libgetopt.a
> ../../src/share/replaygain_analysis/.libs/libreplaygain_analysis.a
> ../../src/share/replaygain_synthesis/.libs/libreplaygain_synthesis.a
> ../../src/share/utf8/.libs/libutf8.a ../../src/libFLAC/.libs/libFLAC.a
> -L/Users/glennm/libOGG-i386/lib
> /Users/glennm/libOGG-i386/lib/libogg.dylib -liconv -lm
> i686-apple-darwin10-gcc-4.2.1:
> /Users/glennm/libOGG-i386/lib/libogg.dylib: No such file or directory
when you tell the linker to use foobar.dylib, it won't go to looking
for anything else. if its not there, its an error.

On Tue, Aug 17, 2010 at 3:12 PM, Paul Davis <paul at
linuxaudiosystems.com> wrote:
> On Mon, Aug 16, 2010 at 11:09 PM, Glenn McCord <glenn.mccord at
gmail.com> wrote:
>
>> 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/grabbag/.libs/libgrabbag.a
>> ../../src/share/getopt/libgetopt.a
>> ../../src/share/replaygain_analysis/.libs/libreplaygain_analysis.a
>> ../../src/share/replaygain_synthesis/.libs/libreplaygain_synthesis.a
>> ../../src/share/utf8/.libs/libutf8.a ../../src/libFLAC/.libs/libFLAC.a
>> -L/Users/glennm/libOGG-i386/lib
>> /Users/glennm/libOGG-i386/lib/libogg.dylib -liconv -lm
>> i686-apple-darwin10-gcc-4.2.1:
>> /Users/glennm/libOGG-i386/lib/libogg.dylib: No such file or directory
>
> when you tell the linker to use foobar.dylib, it won't go to looking
> for anything else. if its not there, its an error.
>
That's the problem really. How do I tell the linker *not* to use
foorbar.dylib? I want it using the static libogg.a file. It seems I
have no control over this via the configure options. With the
configure options I have told libFLAC where to look for my
installation of libOgg, of which it has both static and dynamic libs
available to use. Using options such as...

--enable-static --disable-shared

...has no effect

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/grabbag/.libs/libgrabbag.a
> ../../src/share/getopt/libgetopt.a
> ../../src/share/replaygain_analysis/.libs/libreplaygain_analysis.a
> ../../src/share/replaygain_synthesis/.libs/libreplaygain_synthesis.a
> ../../src/share/utf8/.libs/libutf8.a ../../src/libFLAC/.libs/libFLAC.a
> -L/Users/glennm/libOGG-i386/lib
> /Users/glennm/libOGG-i386/lib/libogg.dylib -liconv -lm
> i686-apple-darwin10-gcc-4.2.1:
> /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.

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
libtool.

Richard Ash

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/grabbag/.libs/libgrabbag.a
>> ../../src/share/getopt/libgetopt.a
>> ../../src/share/replaygain_analysis/.libs/libreplaygain_analysis.a
>> ../../src/share/replaygain_synthesis/.libs/libreplaygain_synthesis.a
>> ../../src/share/utf8/.libs/libutf8.a ../../src/libFLAC/.libs/libFLAC.a
>> -L/Users/glennm/libOGG-i386/lib
>> /Users/glennm/libOGG-i386/lib/libogg.dylib -liconv -lm
>> i686-apple-darwin10-gcc-4.2.1:
>> /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
of interest

checking if g++ static flag -static works... no

and...

checking whether the g++ linker
(/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld) supports shared
libraries... yes

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
> libtool.
>
> Richard Ash
>
>