[vorbis-dev] build process patches

[Jeff Squyres]

On Sat, 30 Dec 2000, Jack Moffitt wrote:

> > - Patch 3: Allows vorbis-tools packages to be linked statically.  The
> > linker flags are in the wrong order for static linking (regardless of your
> > compiler), and the wrong automake keyword suffix is used (LDFLAGS instead
> > of LDADD).  If you configure vorbis-tools with "--enable-static
> > --disable-shared" (these are legal options), oggenc and ogg123 will fail
> > to link properly if libao, libogg, or libvorbis were compiled statically
> > (which is also legal).
>
> libao cannot be compiled statically can it?  I'm fairly sure the
> plugins require it to be dynamic.  They are loaded at runtime with

Actually, you're right, and that brings up another issue: the user is
allowed to specify "--enable-static --disable-shared" to the configure
line in ao.  I found this out the hard way -- after not following vorbis
for a while, and doing a "cvs update" after beta3, it took me a little
while to figure out why oggenc was failing (because ao couldn't find any
.so's).

Since static linking ao doesn't work (as you point out, they are loaded
with dlopen/dlsym), this should either not be allowed, or the docs should
tell the user not to do this.

The latter is probably much easier, since both the --enable-static and
--disable-shared options are built-in to libtool/automake; I don't know if
you can disable them.

It might be possible to print out a big warning during ./configure if the
user selects these options, however.

> dlopen/dlsym.  The others could be, except for things which use libao.

Actually, you can build libao statically as long as you build it
dynamically as well.  i.e., "./configure --enable-static" such that .a
*and* .so files are built.  This allows you to build a binary that
statically links to libao.a, but dynamically links to the pluging .so's at
runtime.

Also, libogg and libvorbis can be built statically regardless of how libao
was built.

> And in fact, the win32 tools which use vorbis and ogg are linked
> statically.  I'll fix the mistakes though...

Thanks.

> > - Patch 4: The Makefile dependency stuff in automake is ***BROKEN***.  It
> > [...automake Makefile dependency stuff snipped...]
> > there are other ways of doing it [yes, they also suck, but they're
> > portable].
>
> I don't know what your point is here.  Yes this is a known issue, but
> automake is not meant to be used when compiling builds for systems
> with proprietary cmpilers.  That's what the tarball from a 'make dist'
> is for, and automake should specifically ensure that that tarball is
> generic.

I think it would be more accurate to say that the
ao/ogg/vorbis/vorbis-tools/etc. CVS trees are not meant to be used with
non-gcc compilers.  There are many projects that use automake in
development trees that allow the use of non-gcc compilers.  For example,
automake itself includes many m4 macros to test for characteristics that
are not specific to gcc.

But you make a good point; I was not looking at the xiph.org's CVS build
process as gcc-only (yes, I'm building at the CVS head with the Solaris
native compilers, not gcc).

Is it documented anywhere that the CVS tree is meant to be gcc-only
(and/or Linux-only)?  More specifically, what's the definition of a
"foreign system"?  This would probably be a good factoid to put on the web
page that describes anonymous CVS access.

> Are you saying that there's a bug and that 'make dist' is not
> buildable?  Or are you trying to use CVS snapshots on foreign systems?

No -- make dist seems to work fine.  The resulting tarballs can be built
with native compilers with no problems.

> I think not having dependency tracking for all the code is quite
> unacceptable, unless no-dependencies only turns it off for Makefile.in
> dependencies (those don't change so often, so it's not that
> inconvienient).

True -- dependency tracking is necessary for developing code.
no-dependencies turns it off alltogether -- there's no "depend" target
(unless you supply one manually, of course).

> Automake is for developers working with CVS code.  If your regularly
> working with vorbis in non gcc unix environments (like Solaris or
> Digital UNIX) then it should be easy to turn this stuff off on your

As shown with the patch in my previous post, this is what I ended up
doing.

However, my $0.02 is that it is important to continue to test with non-gcc
compilers.  While this not an earth-shattering statement, it would be
helpful if the development build process could accomodate other compilers
for the following reasons:

1. Native compilers tend to give better performance than gcc on their own
platforms.  This not only speeds up development (because your runs are
just faster), native development/debugging tools can be more powerful than
gdb (once you start using a memory-checking debugger, you'll never go
back!).

2. All C compilers are not created equal -- as just shown with a few
Solaris-specific issues that I sent to the list (e.g., <alloca.h>).

3. Basing a distribution upon gcc-only testing is dangerous.  I'm not
saying that ogg/vorbis is doing this, but it makes it a bit more annoying
to test when you have to either edit your Makefile.am's, or:

        cvs update
        ./autogen.sh
        rm -f libao*gz
        make dist
        gunzip -c libao*gz | tar xf -
        cd libao*
        ./configure --prefix=...
        make all install

to test a given CVS state on a non-gcc platform.

4. Different warning levels on different C compilers show different
messages.  "gcc -Wall" does *not* show everything.  The IRIX native
compilers, for example, are particularly picky when you turn full warnings
on.

As I mentioned before, we have developed a portable "make depend" script
for our software projects that use automake with gcc or native compilers.
I'd be happy to share it.

It's up to you guys if you want to support this or not.  Given Jack's
response, you probably don't, so this will be the last time that I
complain about it.  :-)  But documenting this decision somewhere would be
good...

{+} Jeff Squyres
{+} squyres at cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.