cvs commit: ports/sysutils/cdrdao/files

[Joerg Schilling]

Marius Strobl <marius at alchemy.franken.de> wrote:

> > I am not shure about the background of this patch, but it seems that you have a 
> > major missconception of the Schily Makefile system.....
> > 
> > 1)
> > The Schily Makefile system does not ignore the exist status except when
> > you are using a broken make program (e.g. smake-1.2a23 that calls 
> > "sh -c command...." instead of "sh -ce command....") or a shell that 
> > incorrectly handles the -e flag. It seems that there sre still peple who do not
> > understand the POSIX shell rules correctly.
>
> What I was refering to is the fact that the unaltered Schily
> Makefile system does ignore the exist status on at least both
> FreeBSD and Solaris when used with GNU make (at least with 3.80
> and 3.81, but AFAIR also with all previous versions I used).
> Regardless of whether that's a bug or not, it's the reason why
> a core dumping avoffset doesn't cause the build of Cdrtools to
> fail when using GNU make.

This is not true:

An unaltered Schily Makefile system does not ignore the exist status
in case you use SunPro make or my smake. So it is obviously a GNU make bug.

This is why GNU make is only the last resort in case that neither smake (the 
preferred make) not SunPro make is available.


> > 2)
> > If avoffset dumps core, you found a serious problem that needs to be fixed.
> > The expected error situations for avoffset (when stack scanning is not possible
> > on a specific platform) is to receive a SIGBUS or a SIGDEV. There is a handler 
> > that catches these signals and calls exit(0). If you see a SIGILL, then you 
> > should check your compiler....or find another reason why an illegal instruction 
> > gets executed while the code only follows a linked list.
> > 
> > Using the Sun C-compiler, I receive a SIGBUS (with address allignement error)
> > on Sparc using 64 bits.
>
> The SIGILL is due to a data access exception. Maybe a FP_OFF of
> 0x10 isn't appropriate for GCC on FreeBSD/sparc64? With GCC 3.4.4
> and 3.4.6 changing FP_OFF from 0x10 to 0 changes the SIGILL into
> a SIGSEGV (I also get a SIGSEGV with FP_OFF = 0x10 when compiling
> w/o optimizations).
> Anyway, until getting to the bottom of the existing layers of
> workarounds and the real problems, adding another workaround in
> order to get cdrdao build again seemed reasonable...

The correct workaround for your problem would be to add a signal handler 
for SIGILL.
I now use:

#ifdef  SIGBUS 
        signal(SIGBUS, handler); 
#endif 
        signal(SIGSEGV, handler); 
#ifdef  SIGILL 
        signal(SIGILL, handler);        /* For gcc -m64/sparc on FreeBSD */ 
#endif 

And it may be useful to add handlers for all other Core dump signals too.


Jörg

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