Re: [Libcdio-devel] libcdio 0.83 release around Oct 27, FreeBSD-8 test

[Rocky Bernstein]

On Thu, Oct 20, 2011 at 3:21 PM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> i began on FreeBSD by reading README.
>
> This statement needs update:
> "At present, there is no support for writing CD's, nor is there any
>  support for reading or writing DVDs. For some of these, there are
>  other libraries (e.g. libdi, libscg, or libdvdread) may be helpful.
> "
>
> There is now low-level support for all MMC commands, including
> those for writing. At least on GNU/Linux, FreeBSD, and Solaris.
>

Ok. The README has been updated.  Thanks.

>
> libburn is able to write all commercially available CD, DVD, and
> BD types. Not all CD modes are supported.
> The same is true for reading of these media.
> libburn works on GNU/Linux, FreeBSD, and Solaris.
>
>
> ------------------------------------------------------------------------
>
> Although i followed README.develop and README.libcdio, i still
> have to do before make (with a git copy of 20 Oct 19:12):
>
>  touch ./doc/version.texi
>  (cd src ; touch cd-drive.1 cd-info.1 cd-read.1 iso-info.1 iso-read.1)
>
> after
>
>  ./configure MAKE=gmake
>
> What instructions am i missing to read ?
>

Did you run autogen.sh? If so and things don't work for you there's probably
something in the way things are set up.


> ------------------------------------------------------------------------
> Compiler warnings:
>
> This time we are on a 64 bit system:
>
>  udf_file.c: In function 'udf_read_block':
>  udf_file.c:242: warning: format '%u' expects type 'unsigned int', but
> argument 3 has type 'size_t'
>
> /usr/include/machine/_types.h:
>  typedef   __uint64_t      __size_t;
>
> So this should better be %lu with an explicit cast to (unsigned long).
>

long isn't necessarily the same as 64bit. Somewhere I saw some a way to
create #defines of the format string to do the right thing independent of
the way longs are defined. If someone wants to research this and supply a
patch, okay. But unconditionally changing the format from %u to %lu whlie
removing a warning here will give add another warning on another system. :-/


>
> The nasty iconv const char problem pops up:
>
>  utf8.c: In function 'do_convert':
>  utf8.c:132: warning: passing argument 2 of 'libiconv' from incompatible
> pointer type
>
> It can be solved by defining a macro by a lengthy autotools check.
> But actually it is harmless.
>

I think someone else noticed this and it is fixed now.


>
>
> This one should be harmless, too:
>
>  FreeBSD/freebsd_ioctl.c: In function 'get_mcn_freebsd_ioctl':
>  FreeBSD/freebsd_ioctl.c:224: warning: pointer targets in passing argument
> 1 of 'strdup' differ in signedness
>
>
> This one appears during "make install":
>
>  /bin/sh ../../libtool --mode=install /usr/bin/install -c  'libudf.la'
> '/usr/local/lib/libudf.la'
>  libtool: install: warning: relinking `libudf.la'
>
>
> ------------------------------------------------------------------------
> make check (as README.libcdio proposes):
>
>  $ gmake check
>  ...
>  gmake  check-TESTS
>  gmake[3]: Entering directory
> `/usr/home/thomas/projekte/libcdio_dir/libcdio-0.83git.B11020/test/driver'
>  Incorrect: cdda.cue doesn't parse as a CDRWin CUE file.
>  Incorrect: isofs-m1.cue doesn't parse as a CDRWin CUE file.
>  ++ WARN: Can't get file status for /test/data/cdda.cue:
>  No such file or directory
>  ++ WARN: could not retrieve file info for `/test/data/cdda.cue': No such
> file or directory
>  ++ WARN: can't open nrg image file /test/data/cdda.cue for reading
>  Can't open cdda.cue
>  FAIL: bincue
>  PASS: cdrdao
>  PASS: freebsd
>  SKIP: gnu_linux
>  PASS: mmc_read
>  PASS: mmc_write
>  ++ WARN: could not retrieve file info for `/test/data/p1.nrg': No such
> file or directory
>  ++ WARN: can't open nrg image file /test/data/p1.nrg for reading
>  Can't open Nero image file: /test/data/p1.nrg.
>  FAIL: nrg
>  SKIP: osx
>  Temp directory is /var/tmp/
>  PASS: realpath
>  SKIP: solaris
>  SKIP: win32
>  =====================================
>  2 of 7 tests failed
>  (4 tests were not run)
>  Please report to address@hidden
>  =====================================
>

Looks like the same problem as you reported before. See the previous comment
and suggestion. Because this is now on two different OS's, it is probably
not an OS-specific thing. Rather a configuration kind of thing.


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