Here's an updated set of patches to fix some problems with the build
process. These patches are relevant to the CVS head as of 30 Dec 2000.
Overview:
- Patch 1: Allowing the user to set CFLAGS/LDFLAGS before running
configure in all four modules. All these patches do is essentially:
cflags_save="$CFLAGS"
ldflags_save="$LDFLAGS"
# ... stuff to set CFLAGS and/or LDFLAGS
CFLAGS="$CFLAGS $cflags_save"
LDFLAGS="$LDFLAGS $ldflags_save"
Yes, there's other ways of doing it, but this was low-cost, easy to
understand, and modified very little configure.in code that is already
there.
Applies to:
ao/configure.in
ogg/configure.in
vorbis/configure.in
- Patch 2: Allow --prefix to specify where libao, libogg, and libvorbis
live. It's a real pain to have to specify --with-ogg-prefix=foo (etc.) on
all those configure lines. The most common case is that they're all
installed in the same place anyway. Hence, the --prefix directory should
be checked for libogg (and the rest) as well.
Applies to:
vorbis/acinclude.m4
vorbis-tools/acinclude.m4
- 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).
Applies to:
vorbis-tools/ogg123/Makefile.am
vorbis-tools/oggenc/Makefile.am
- Patch 4: The Makefile dependency stuff in automake is ***BROKEN***. It
adds CFLAGS that simply are gcc-specific (the automake manual clearly
states this). As such, you can't compile with native (i.e., non-gcc)
compilers (where you can get a substantial performance boost). To a)
remove the automake dependency stuff and b) make it portable to other
compilers, you have to add "no-dependencies" to the AUTOMAKE_OPTIONS
line
in every Makefile.am.
Yes, this sucks, and yes, dependencies are important for developers. But
there are other ways of doing it [yes, they also suck, but they're
portable].
Applies to:
every Makefile.am that has .c/.h files in them
(I might have missed some in ao; I only did the ones relevant on
Solaris)
{+} Jeff Squyres
{+} squyres@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"
<HR NOSHADE>
<UL>
<LI>TEXT/PLAIN attachment: patch1
</UL>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch1
Type: application/octet-stream
Size: 3396 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20001230/546f2017/patch1-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch2
Type: application/octet-stream
Size: 2154 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20001230/546f2017/patch2-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch3
Type: application/octet-stream
Size: 1620 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20001230/546f2017/patch3-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch4
Type: application/octet-stream
Size: 2692 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20001230/546f2017/patch4-0001.obj
Jeff Squyres wrote:> > Here's an updated set of patches to fix some problems with the build > process. These patches are relevant to the CVS head as of 30 Dec 2000.An idea: as long as the ao, ogg, vorbis modules are distributed as one, why not add a toplevel Makefile to build them all? Cheers, Segher --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> - Patch 1: Allowing the user to set CFLAGS/LDFLAGS before running > configure in all four modules. All these patches do is essentially: > Yes, there's other ways of doing it, but this was low-cost, easy to > understand, and modified very little configure.in code that is already > there.That seems reasonable.> - Patch 2: Allow --prefix to specify where libao, libogg, and libvorbis > live. It's a real pain to have to specify --with-ogg-prefix=foo (etc.) on > all those configure lines. The most common case is that they're all > installed in the same place anyway. Hence, the --prefix directory should > be checked for libogg (and the rest) as well.Also reasonable.> - 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 dlopen/dlsym. The others could be, except for things which use libao. And in fact, the win32 tools which use vorbis and ogg are linked statically. I'll fix the mistakes though...> - Patch 4: The Makefile dependency stuff in automake is ***BROKEN***. It > adds CFLAGS that simply are gcc-specific (the automake manual clearly > states this). As such, you can't compile with native (i.e., non-gcc) > compilers (where you can get a substantial performance boost). To a) > remove the automake dependency stuff and b) make it portable to other > compilers, you have to add "no-dependencies" to the AUTOMAKE_OPTIONS line > in every Makefile.am. > > Yes, this sucks, and yes, dependencies are important for developers. But > 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. 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? 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). 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 local copies. If you're just building vorbis for weird platforms, you should be using 'make dist', since that's what it's for. I'll see if I can't get this stuff committed this weekend. Trying to get some updated beta3 stuff out the door. jack. --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Jack Moffitt <jack@icecast.org> writes:> libao cannot be compiled statically can it? I'm fairly sure the plugins > require it to be dynamic.This may be a stupid question, but are dynamically loadable plugins really worth the grief? It seems like, under Linux at least, there's only a small, stable set of output methods, which could just be compiled directly into libao on a per-platform basis. --Mike --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Jack Moffitt <jack@icecast.org> writes:> It doesn't work when you try to integrate things into standard packaging > systems. How am I to know which set of libs you have? Sure, OSS doesn't > require any libs, but ALSA does. Monty uses alsa. I use Esound. Both > require libs, and neither of us has the other one. We both like to use > packages (me, rpm, monty, debian) for installing things.Ok, I guess it was a stupid question; I can't think of anything better either. (I'm a debian guy, too.) This is actually kind of an obnoxious problem in general; reminds me of Windows (/me makes gagging sounds and motions).> Compiling it statically just doesn't work. Doing it dynamically turned > about to be easy and fixed the problem correctly IMO. What grief have you > had? :)The grief I ran into was using the 'debug' or 'profile' targets in ao/src/Makefile, which fail to include the '-DAO_PLUGIN_PATH=\"${exec_prefix}/lib/ao\"' flag, which causes the library to silently look for plugins in /usr/local/lib/ao by default, which then causes ogg123 to fail with a fairly inscrutable error message. It seems to me that this needs to be fixed somehow. My thought would be to (1) make sure that flag gets included for the reasonable targets (including 'debug', 'profile'), (2) remove the default, as it's not really useful, certainly not as useful as discovering this problem at compile time, and (3) maybe add a little text to the ogg123 error message to indicate, say, the exact filename not being found, instead of just saying "no such device". --Mike -- [O]ne of the features of the Internet [...] is that small groups of people can greatly disturb large organizations. --Charles C. Mann --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Segher Boessenkool <segher@wanadoo.nl> writes:> Monty wrote: > > Linux libc > > Russian roulette especially should have driven this home over the past > > five years. > > That's not Russian roulette; with Russian roulette you can win, with > Linux libc (especially the glibc s**t), it's a lose-lose situation.FWIW, I've been using debian for the last five (?) years and I can't recall having had problems like this. At worst, if something breaks, I just upgrade to the latest glibc, and off I go. (I *have* experienced these problems under Windows.) I also agree, though, that it's very important that static linking be possible. --Mike -- [O]ne of the features of the Internet [...] is that small groups of people can greatly disturb large organizations. --Charles C. Mann --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.