[vorbis-dev] build process patches

[Jeff Squyres]

On Sat, 30 Dec 2000, Jack Moffitt wrote:

> > 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.
>
> I thought this was disabled, with the no-static option that I
> supplied?

Actually, no.  AM_DISABLE_STATIC only sets the default -- it does not
actually allow/disallow anything.

> > 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.
>
> That sounds kinda icky :)

Yes.  :-)  But there are two reasons to do it this way:

1. There are sysadmins out there (self included) who tend to prefer static
binaries, even if they are large.  When you have to support many kinds of
software -- and particularly many *versions* of many different software
packages -- the individual packages (or groups of packages, such as in
vorbis' case) get installed into their own locations, such as

        /usr/local/packageA-version
        /usr/local/packageB-version
        /usr/local/vorbis-version
        # etc.

And if you're on AFS, like we are at Notre Dame, the paths can be much
longer than this.  When an enterprise uses this model, you have many
workstations that are individually sysadmin'ed, and only mount the
distributed filesystem for the enterprise-wide software.  Hence, the IT
department doesn't necessarily control the default linker path.  So it's
not as simple as adding another path in and then running ldconfig.  And
that's not a good model anyway, if you want to be able to switch versions
of software on the fly.

If each of these packages requires one or more entry in the
LD_LIBRARY_PATH, it can get quite cumbersome.  That is, the sysadmin has
to make centralized additions to PATH, MANPATH, and LD_LIBRARY_PATH.  Not
only does this take up environment space (which can be an issue,
particularly with long pathnames such as in AFS), it's also one more thing
to maintain (PATH is unavoidable, and MANPATH is sometimes unavoidable).
Hence, if a Lazy Sysadmin has the option, they'll just link it statically
and chose one less thing to have to maintain.

For the Tao of Programming tells us:

        "Even though a program is but 3 lines long, someday it will have
        to be maintained."

2. If you ever want to run a job via cron or some other automated
mechanism, running something that requires a LD_LIBRARY_PATH means either
having a really long cron entry or writing a script that does necessary
setup before invoking the actual executable.  This is typically a pain.
You either get a really long/cumbersome cron/at/whatever entry, or you
write a new script, which a) has to be put somewhere and maintained
through different versions of the software (to change the
LD_LIBRARY_PATH), and b) violates the Tao principle from above.

Hence, some sysadmins may tend to avoid these issues and just link things
statically.

There are countless variations on this scheme, so we don't need to get in
to a sysadmin technique comparison on the list.  Indeed, this isn't really
in the scope of vorbis-dev, but I wanted to state why I tend to compile
things statically -- I'm lazy.  :-)  Oh, and we have oodles of RAM, so
executable size isn't an issue.

Not that I'm going to run an automated oggenc job via cron (although that
would be amusing -- have some of our nightly status scripts send messages
that automatically queue up on xmms... hmmm... "Good Morning, Jeff.
There were three attempted breakins last night.  The backups ran
successfully.  Dr. Lumsdaine's Windows machine rebooted 17 times..."), but
old habits die hard.  :-)

> And how are these projects dealing with no dependency information?
> Is there a way to use an AM_CONDITIONAL to turn on and off dependency
> stuff?  That might be a good comprimise in the situation.

I can only speak for my project (LAM/MPI) -- we wrote a portable "make
depend" script.  Hence, we have a top-level Makefile.depend that has a
"depend" target that gets included in all the Makefile.am's via automake's
"include" directive ("include" gets expanded to make the Makefile.in, so
it's not a portability issue for make).  The "depend" target invokes our
script.

Hence, we still have "make depend", but it invokes our script, not the
automake stuff.

Per your request from below, I'll send you this stuff off the list.  If
others are interested, let me know, and/or have a look at
http://www.mpi.nd.edu/lam/cvs/ -- we don't include this stuff as part of
the normal distribution.

> [snipped]
>
> When I said foreign system I was thinking specifically of native cc on
> solaris and on digital unix.  Both cases wehre gcc is inferior to the
> native compiler (so much so that native compiles should be the norm).
> That is definately a note for documentation.  This mostly stems from
> the fact that we tend to do all the code in linux/gcc and then build
> on other platforms at the end (even win32) with the native compilers.
> It seems to work well, but doesn't accomodate the native compiler
> developers like yourself.

Yeah.  I'm just being whiney.  :-)

{+} 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.