Re: [Bug-xorriso] building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD

[Thomas Schmitt]

Hi,

>   libburn-1.4.4/libburn/.libs/libburn.so.4.97
>   libisoburn-1.4.4/libisoburn/.libs/libisoburn.so.1.100
>   libisofs-1.4.4/libisofs/.libs/libisofs.so.6.80

Yay ! 
I do not use the third suffix number on Linux, anyway.
So this numbering scheme is fully functional.


> The line "SHARED_LIBS += magic 4.2 #1.0" in ports' Makefile does
> renumbering, but I don't know why do so.

Maybe for clueless upstream ?

In two days is the 10th anniversary of the libburnia libburn fork,
which i immediately joined as impatient user og libburn-0.2.
During the first months i had no clue about .so numbering and the
setting in libburn's configure.ac was wrong. So the first suffix
incremented and rolled over quite randomly. Several packagers made
their own patches until one of them showed mercy and gave me a
quick tour through the LT_CURRENT, LT_AGE, LT_REVISION concept.

Since then i keep (LT_CURRENT - LT_AGE) constant to express the
compatibility of the API and ABI of the libraries.

But in GNU autotools i often found the triple poorly mapped to
the systems' .so numbering schemes. So i have to edit my local files
and write documentation how to achieve the appropriate .so numbers.

--------------------------------------------------------------------

libburn and cdrskin now learned to disable the use of the Immed bit.
  http://libburnia-project.org/changeset/5725
  http://libburnia-project.org/changeset/5726

Hopefully i managed to disable it by default on OpenBSD.
The symptom would be that the blanking procedure ends properly and
that the pacifier messages give no progress percentage

  cdrskin: blanking ( done 99.0% , 25 seconds elapsed )

but rather look like

  cdrskin: blanking ( synchronous , 24 seconds elapsed )

It would be possible to checkout libburn from SVN and to copy the
source files in the ./libburn directory to the ./libburn directory
of GNU xorriso. But xorriso would report "1% done" from start to end.

I will next teach xorriso and its cdrecord emulation to disable Immed
on request of the user and to show appropriate pacifier messages.
When done, i will upload a new xorriso-1.4.5.tar.gz and give you a note.

--------------------------------------------------------------------

As for finding out whether operating system or drive are to blame for
the very unusual behavior:

- Do you have the opportunity to try the drive with FreeBSD, Linux, or
  Solaris ? That's the three systems which i have myself on real iron.
  Interesting would be whether cdrecord with -immed or libburn based
  programs like xorriso or Xfburn show the same problems as with OpenBSD.

- Do you know the code parts in the OpenBSD kernel where the REQUEST SENSE
  command gets issued after the previous command indicated availability
  of Sense data ?
  Would it be possible to put a print there which tells whether the
  Sense data bytes
     70 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  really stem from the REQUEST SENSE command ?
  (If not, then they get generated by some driver code in the kernel ...)


Have a nice day :)

Thomas