similar to: Please gix getopt

1. ogg123 still won't build systems that don't have <getopt.h>. Was anything ever decided on how to procede with that? oggenc supplies its own getopt implementation. The only function really in question is getopt_long(), because getopt() is standard POSIX. See http://www.xiph.org/archives/vorbis-dev/200012/0359.html for a discussion of this issue. 2. Also, NAME_MAX is used in

I sent a message about 2 weeks ago about build problems at the head of the CVS tree with non-gcc compilers on POSIX systems, although I didn't correctly identify the link problems as being static-library only (see my previous mail about "static link broken"). Some problems have been fixed, but some still seem to be there. I have edited my original mail to list the problems that

getopt() seems to be on all the Unix flavors that I can check (Solaris, IRIX, AIX, HP-UX, Linux). getopt() may be a standardized POSIX function...? I'm not sure offhand. Regardless, I think it's safe to assume that it's in all flavors of Unix -- oggenc/ogg123 need not include a local version of it for POSIX builds. Indeed, the getopt.c that is in oggenc is not friendly to the Sun

There's some compilation issues on Solaris with the native compilers with the current CVS head. OGGENC: ======= -- "oggenc.c", line 202: warning: improper pointer/integer combination: op "=" I believe the problem here is that rindex() is prototyped in <strings.h>, which is not included. This may be a sun-specific thing. OGG123: ======= -- "ogg123.c",

This patch (along with all the previous patches) gets oggenc and ogg123 working. This does not get vorbiscomment working, although I assume that would be trivial -- just add the getopt stuff to the project just like I did in ogg123. In addition to this patch, as I just mentioned, getopt1.c getopt.h and getopt.c need to be copied from oggenc to ogg123 and added. The host check in

It seems that configuring/building with "--enable-static --disable-shared" causes some problems with building vorbis-tools -- the Makefile.am's in oggenc and ogg123 do not appear to be correct. That is, if you build ao, ogg, and vorbis statically and try to compile oggenc or ogg123, you'll get unresolved symbol linker errors. This happens on all POSIX architectures and

I notice that the user is not able to set their own CFLAGS or LDFLAGS in the ao, ogg, vorbis, and voribs-tools projects. Is there a reason for this? I understand the fact that these modules want to set extremely high optimization flags, and that most users won't know what these are offhand, but there are times when it is useful for the user to specify their own CFLAGS/LDFLAGS. For example,

Since vorbiscomment is being resurrected in a new form, can someone please fix the vorbis-tools/vorbiscomment/Makefile.am? There's two things wrong: 1. Using _LDFLAGS doesn't allow the user to specify their own LDFLAGS. _LDADD or _LIBS should be used instead. 2. The order of libraries is wrong such that it won't link properly when compiled statically. Here's a trivial

Here's a propsed heavy-duty solution for your UTF-8 problems. I'm including a patch in this message, but I'll put the new files on my web site at http://rano.org/tmp/xiph_files.tar.gz I've tested this by running vorbiscomment with and without -DHAVE_ICONV=1 in vorbis-tools/share/Makefile. It seems to work. Changed files: acinclude.m4: Add a test for nl_langinfo(CODESET). This

Hi Jean-Marc, Am 17.04.2009 um 13:35 schrieb Jean-Marc Valin: > It should be using getopt1.c when getopt isn't available.c. Can you > check why it doesn't? In any case, that's only required for the Ogg > tools, not for the library. config.log says ac_cv_func_getopt_long=no ac_cv_header_getopt_h=no ac_cv_lib_gnugetopt_getopt_long=no LIBOBJS='

After downloading the nightly snapshot last night, I've spent a good part of the day trying to build the package with Borland C++Builder 4. I have some things to report, and also need some help. [Note: this message is long and messy :)] {Converting DSP files to BPR files} I made the necessary BPR files from the DSP files with the Visual C++ Project Conversion Utility. This works okay

Hi, Attached are patches for the beta 4 distribution, fixing minor problems in RPM spec files. One question: are there any reasons not to include vorbiscomment in the vorbis-tools binary package? I've added the long-awaited utility program into the revised spec file, but I wonder if it is a wrong change... Regards, -- KAJIYAMA, Tamito <kajiyama@grad.sccs.chukyo-u.ac.jp> diff -ru

This patch cleans up the vorbis-tools Makefile.am files so they work with both automake 1.4 and 1.6. Some changes to configure.in were also needed in order to get things to work (and to fix some ac 2.50 issues). Please remove config.h from cvs as it is a generated file and empty anyway. automake 1.6 isn't really incompatable with 1.4, it's just more picky about you sticking to the rules:

Hi All, For my new file (and thus mp3) server I've decided to switch completely to Ogg Vorbis. This means having to reencode ~30GB worth of 128Kb MP3's, but i figured that it would all be worth the effort. So I downloaded the sources for libogg, libvorbis and vorbis-tools and fired up my trusty old compiler. libogg and libvorbis built and installed like a charm. Not so for

The following patch (based off of the current CVS tree) is necessary to compile Speex on IRIX (or any other system that doesn't include getopt_long in the system libraries). I would suggest further that src/getopt_win.h be renamed to getopt_long.h since it's not just Windows that lacks getopt_long. Michael Index: configure.in

Hello. Attached are some patches that some Debian users of vorbis-tools have sent to our BTS over the years (numbers refer to Debian bugs). It'd be nice to see them integrated. They apply cleanly to SVN as of today. The largefile_support one is a bit bigger than just the configure.ac since the submitter adviced that config.h got included in all C source files before the standard includes,

Hello. Attached are some patches that some Debian users of vorbis-tools have sent to our BTS over the years (numbers refer to Debian bugs). It'd be nice to see them integrated. They apply cleanly to SVN as of today. The largefile_support one is a bit bigger than just the configure.ac since the submitter adviced that config.h got included in all C source files before the standard includes,

It should be using getopt1.c when getopt isn't available.c. Can you check why it doesn't? In any case, that's only required for the Ogg tools, not for the library. Jean-Marc Dagobert Michelsen a ?crit : > Hi, > > I have problems compiling speex 1.2rc1: > >> /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I. - >> I.. -I../include

Hi, The following changes allow vorbiscomment to read and edit the tags for the first occuring vorbis stream in a muxed (and chained) Ogg bitstream, while retaining the renormalisation. I've tested it on a number of combinations of muxed and chained streams, using the write comments from file option for vorbiscomment to rewrite the comment header and then cmp for binary differences. Seems

Speaking of ogg123 fixes and Solaris... <getopt.h> doesn't appear to exist in Solaris. Hence, ogg123 won't compile on Solaris at all (even with gcc). I originally mentioned this back in November (http://www.xiph.org/archives/vorbis-dev/200011/0291.html). Can this be fixed? {+} Jeff Squyres {+} squyres@cse.nd.edu {+} Perpetual Obsessive Notre Dame Student Craving Utter Madness