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

[Rocky Bernstein]

Executive summary: Thanks for the detailed tests and report.

Changes have been made and with luck this addresses the valid concerns.

On Wed, Oct 19, 2011 at 6:05 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> the diff between your and my versions of the solaris driver looks ok.
> (Small cosmetic differences and use of snprintf() instead of sprintf())
>

snprintf is preferred for security reasons. I've modified the solaris driver
and also found one instance in the
GNU/Linux driver.

>
> There is one severe build obstacle left on OpenSolaris:
> System headers define macro FS which is also used as class name in
>  include/cdio++/iso9660.hpp
> See below for details.
>

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.


>
> The problems which i had with drive enumeration are mainly about
> the difference between drive addresses for POSIX reading and
> the drive addresses for SCSI transactions.
> libburn has to sort this out, because libcdio's cdio_get_devices()
> has no knowledge about which device class is desired.
> Similar on FreeBSD.
>
>
> So if the FS problem is solved, i assume that the libcdio tarball
> of 0.83 will be usable on OpenSolaris.
> (There remain problems with the files delivered by git, though.)
>
>
> > It would be nice if you could do some testing with a real CD.
>
> My old version works fine under libburn and GNU xorriso.
> It recognizes, burns, and reads CD-RW and DVD+RW during libisoburn
> regression tests.


I'm not sure what this means. That at sometime in the past there was a
tarball that did the kinds of things you used want it to do? Well, ok. I
guess this provides a baseline.


>


> Now for building the new one ...
>
> ========================================================================
> First on GNU/Linux:
> ========================================================================
>
> - There still is the problem of missing documentation files in a
>  git checkout:
>    libcdio.texi:4: @include `version.texi': No such file or directory.
>    make[3]: *** No rule to make target `cd-drive.1', needed by `all-am'.
> Stop.
>  Workaround:
>    touch ./doc/version.texi
>    (cd src ; touch cd-drive.1 cd-info.1 cd-read.1 iso-info.1 iso-read.1)
>

This is because there is still the problem of your not reading/following
developer instructions.

>
> ------------------------------------------------------------------------
>
> + The newly built libcdio is recognized by GNU xorriso's build system
>  and links with it.
>  (Two harmless new warnings pop up because of xorriso's gcc -Wextra.
>   I will fix them in libburn.)
>
>  It burns a backup session on DVD+RW.
>

Ok. Good so far

>
> ------------------------------------------------------------------------
>
> - Another file is missing with make dist


   make: *** No rule to make target `ChangeLog', needed by `distdir'.  Stop.
>  Workaround:
>    touch ./ChangeLog
>  (Without previous "make" there would also be missing doc/libcdio.info)
>

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".

I've now run make distcheck, and make dist from a totally cloned git
repository. I don't have a problem.

I'll happily provide tarballs if you need them. I've just put the latest
with changes mentioned in this post at
http://bashdb.sf.net/bashdb-0.83git.tar.bz2



>
> ========================================================================
> SunOS solaris 5.11 snv_134 i86pc i386 i86pc Solaris
> ========================================================================
> With the produced tarball:
>
> - Unmodified, it does not build here due to a known problem:
>  (see
> http://lists.gnu.org/archive/html/libcdio-devel/2010-05/msg00005.html)
>
>  In file included from iso9660.cpp:24:
>  ../../include/cdio++/iso9660.hpp:151: error: expected identifier before
> numeric constant
>  ../../include/cdio++/iso9660.hpp:151: error: expected unqualified-id
> before numeric constant
>  iso9660.cpp:295: error: expected `}' at end of input
>  ../../include/cdio++/iso9660.hpp:147: error: expected unqualified-id at
> end of input
>  *** Error code 1
>  make: Fatal error: Command failed for target `iso9660.lo'
>
>  Workaround:
>    I undefined FS at the beginning of iso9660.hpp
>
>      #include <cstring>
>      using namespace std;
>
>    + #ifdef FS
>    + #undef FS
>    + #endif
>
>      /** ISO 9660 class.
>      */
>
> ------------------------------------------------------------------------
>
> - A few new occasions of a known warning have popped up.
>  Quote from
>    http://lists.gnu.org/archive/html/libcdio-devel/2010-05/msg00005.html


>  "Several source files do not comply to the demand of Solaris man
>   lfcompile


Solaris man Ifcomple? what's that?


> to define eventual _FILE_OFFSET_BITS before including any
>   system headers. I see this macro in autools generated header config.h."
>
>    In file included from ../include/cdio/types.h:34,
>                     from ../include/cdio/cdio.h:35,
>                     from udf1.c:29:
>    ../include/cdio/cdio_config.h:332:1: warning: "_FILE_OFFSET_BITS"
> redefined
>    In file included from /usr/include/sys/types.h:33,
>                     from udf1.c:28:
>
>  
> /usr/gcc/4.3/lib/gcc/i386-pc-solaris2.11/4.3.3/include-fixed/sys/feature_tests.h:218:1:
> warning: this is the location of the previous definition
>
>  Affected are these includers:
>    tracks.c
>    sample3.c
>    sample4.c
>    udf1.c


I just reread that link. I don't understand what you are talking about
either time. The C programs listed above are example programs.  And I was
able to compile these on Solaris.

>

 The occasion which i reported in above message are repaired, obviously.
>

It may be obvious to you, but I don't understand what you are talking about.
I think a while back someone else had brought up the problem of compiling
some of the example programs. There, truncated headers in
<cdio/config_cdio.h> caused a problem there.  So I include the entire C
config header file, config.h, as <cdio/config_cdio.h> . Perhaps this
impinges on some problem you are trying to express?



>  Proposed workaround (not applied here):
>    Move #include "config.h" to a place above ithe other includes.


I'm okay with the fact that on some OS's you might have to adjust the
includes.

>


> ------------------------------------------------------------------------
>
> - This warning does not appear in my old mails to libcdio-devel:
>
>    cd-info.c: In function 'main':
>    cd-info.c:1103: warning: implicit declaration of function 'bzero'
>    cd-info.c:1103: warning: incompatible implicit declaration of built-in
> function 'bzero'
>
>  Might be dangerous, because man bzero says:
>    void bzero(void *s, size_t n);
>  and the compiler could believe to deal with
>    int bzero();
>  which could shift the parameter values on the call stack.
>

I've added a conditional include of <strings.h> perhaps this will address
this.


>
> ------------------------------------------------------------------------
>
> + After make install, it passes the libisoburn regression tests,
>  which include inquiry and burning of CD-RW and DVD+RW.
>

Okay. Good news. Thanks for the detailed testing and reporting.

>
> ------------------------------------------------------------------------
>
>
> Have a nice day :)
>
> Thomas
>
>
>