libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] libcdio 0.83 release around Oct 27


From: Rocky Bernstein
Subject: Re: [Libcdio-devel] libcdio 0.83 release around Oct 27
Date: Thu, 20 Oct 2011 07:08:32 -0400

On Thu, Oct 20, 2011 at 2:24 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> > I've taken your suggestion and added the #ifdef. I wonder though if I had
> >  used
> >
> > class ISO9660  { ... }
> >
> > class ISO9660::FS if that wouldn't have also solved the problem better
> since
> > FS in this case probably wouldn't have been considered a token by the C
> > preprocessor.
>
> I am not skilled in C++.
>

Apparently neither am I. I had expected C++ to have more of the flexibility
in defining nested classes that Perl and Ruby have. We'll stick with what's
currently in git.



> ...
> There are instructions ? :o)
>

Yes. They start "README".

>
>
> > Part of the way things are the way they are is because that's how
> autotools
> > works. I worry about folks who don't read the instructions, don't
> understand
> > autotools (which is admittedly obstruce) and run "make dist".
>
> Hmmm. README.libcdio says i shall read README.develop.
> But that does not mention
>  doc/how-to-make-a-release.txt
> which i now found by grepping for "distcheck".
>

how-to-make-a-release.txt are my personal notes. At one time they seem to
have been in version control. It's nice that you go through such lengths to
try to smoke out problems. It feels to me that this effort is a little
misdirected. That is instead of doing this, just reading the READMEs you
cite should be sufficient.

>
>
> > I'll happily provide tarballs if you need them.
>
> It's just that my Solaris has no git and that i am reluctant to
> still download packages from Oracle.


I've never had problems compiling git from source. (And yes,
opencsw.orgdoes provide a package for git were you not so reluctant.)



> ...
> > Solaris man Ifcomple? what's that?
>
>
> Developer instructions for Large File Support on 32-bit systems. :))
> E.g.
>  http://compute.cnr.berkeley.edu/cgi-bin/man-cgi?lfcompile+5
>
> It prescribes
>  "Set the compile-time flag _FILE_OFFSET_BITS  to  64
>   before including any headers."
>
> libcdio's config.h has:
>  /* Number of bits in a file offset, on hosts where this is settable. */
>  #define _FILE_OFFSET_BITS 64
>
> In the four test programs, config.h is included after some system headers.
>

Ah. So the problem we are trying to solve is using Sun's C compiler on
Solaris 64-bit systems with the largefile support to compile the example
programs. In my view somewhat border-case thing to do. Especially as Solaris
use will probably be declining.

The example programs are mere suggestions; although it would be nice if one
didn't have to modify them to compile them, I don't want to overly
complicate the example programs for such edge cases.

I've added a note in the example README that some adjustment may be needed
in certain cases to compile the programs.

...
>
>
> > Okay. Good news. Thanks for the detailed testing and reporting.
>
> I meanwhile remembered that libcdio has a test suite too.
>
> If you want me to run any tests, give me instructions for dummies.
>

Run "make test". Or better in my opinion: "remake test". If you use "make",
GNU make is preferred.


>
> I also have a real FreeBSD 8 at hand.
> (And a virtual GNU/Hurd, too ... but i am still negociating with
>  the developers how to drill a tunnel from userspace to the old
>  Linux 2.0 drivers for SCSI and ATAPI which sit in gnumach.)
>

If you could test with these that'd be fantastic. Many thanks!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]