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

Re: cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present



scdbackup@gmx.net wrote:

> Hi,
>
> > I don't care about libburn, it is so broken that it does not even complete
> > it's "configure" run:
> > checking for a BSD-compatible install... /opt/sfw/bin/ginstall -c
> > ./configure: line 19396: syntax error near unexpected token `in'
> > ./configure: line 19396: `for ac_header in'
>
> That looks much like an icculus.org/burn libburn-0.2 tarball

This is the latest I could find.

> or CVS version prior to about march 2006. (Newer bash versions
> accept an empty "for" list. I noticed that problem only on
> a SuSE 7.2 system. Meanwhile our ./configure is fat but legal.) 

Whether newer bash version follow newer POSIX shell documentations does not 
matter. A configure script has to be written in a way that still works with 
a Bourne shell from 1979.


> The stable current version is available as
>   http://libburn-download.pykix.org/releases/libburn-0.2.6.1.tar.gz
> resp. with identical code base as
>   http://scdbackup.sourceforge.net/cdrskin-0.2.6.pl01.tar.gz

It still does not have a working "configure".

After fiddling with configure, it prints warnings about completely broken
printf formats and signed array subscripts that should never appear.

still much more promising than the libcdio junk ;-)

> It seems to compile on all the contemporary Linux distros.
> I would appreciate any bug reports.

Well, Linux is not the world....and FreeBSD is less frequently used than 
Solaris. In fact, it seems all *BSDs together did get about half of the market 
share of Solaris aound 2004 and ad Solaris did gain 2 million new users since 
then, things look different now.


> > > So - if you want advise - disable that new auto-scan feature
> > > unless an explicit drive address is missing.
> > As this is not doable before you did scan, it would need toi
> > stay similar to how it is.
>
> But you do know wether there is a dev= option before you
> start with the bus scan, don't you ? In that case it seems
> wise to me to omit that total scan and to only touch the desired
> drive(s). (I mean, i learned this from *you*. It is much better
> a strategy than the one of old libburn. You should not give
> up anything of the stability of cdrecord by scanning without
> need.)

It looks like you are misunderstanding the libscg interface.
Have a look at the syntax definitions in the source files....

> A few months ago i had an ill DVD-ROM which stalled libburn's
> bus scan as long as DMA was on. In that state it also stalled 
> cdrecord dev=ATA -scanbus on a Linux 2.6 kernel.

This looks like a Linux bug. I did see similar reports that let me asume
that Linux frequently ignores timeouts.... Another reason not to use Linux ;-)


> > #ifdef  USER_HZ 
> >        tmo *= USER_HZ; 
> >        if (tmo) 
> >                tmo += USER_HZ/2; 
> >#else 
> >        tmo *= HZ; 
> >        if (tmo) 
> >                tmo += HZ/2; 
> >#endif 
>
> The compiler still complains about HZ.
> I guess the file necessary for USER_HZ is not included.
>
> I flatly inserted the usual header files from some of my
> own programs into libscg/scsi-linux-sg.c , but no USER_HZ
> did show up.

Bad planning in Linux as usual :-(


> > > The drive /dev/hgd did never interact with cdrecord.
> > Then this 
> > #if LINUX_VERSION_CODE <= 0x020600 
> >         if (use_ata) 
> > #endif 
> >         for (i = 0; i <= 25; i++) { 
> >                 js_snprintf(devname, sizeof (devname), "/dev/hd%c", i+'a'); 
> > should work....
>
> After make clean ; make : Yes.
> (No new cdrecord binary emerges without make clean)

Not correct.... read the documentation..... "make relink" is sufficient.

Future versions of the makefile system will support detecting updated libraries 
and you may then benefit from this feature in case you are using the Solaris 
"ld" and either Sun-Pro make or 'smake'.

The GNU ld is too dumb for this feature.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily



Reply to: