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 <[email protected]> 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 > > >
