Re: Problems with 2006Q3

[Hrvoje Habjanić <hrvoje.habjanic%zg.t-com.hr@localhost>]

On Friday 03 November 2006 09:08, Joerg Sonnenberger wrote:
> On Fri, Nov 03, 2006 at 08:54:42AM +0100, Roland Illig wrote:
> [skip long explaination]
>
> > This is rather interesting. It looks good, I only fear that the name
> > "-no-std-libs" is a little too generic. It also reminds me of the gcc
> > -nostdlib option, which _might_ be confused with yours. Since yours is a
> > hack especially for Tru64, maybe the option could have "osf1" or "tru64"
> > in its name?
>
> One question remains for me -- why should it not be the default
> behaviour? E.g. why should the wrapper not *force* it transparently?
> That would make the need for the option go away.

I would vote for that also. While building other packages, inclusion from 
system libraries messes up linking of "local" libraries. I think that the 
best solution would be to put libc & libm (like links) in lib directory of 
pkgsrc binary tree. Then you can skip all that mess when misc libraries get 
included from system dirs rather than pkgsrc lib dir.

Best example is ghostscript. While building it, configure script found libX* 
libs in /usr/lib, and added -L/usr/lib. BUT, at the same time, in /usr/lib is 
libz (again), and guess what - it gets included instead of one in pkgsrc lib 
dir, and you get unresolved references ... it's a real mess. :-/

>
> > Wouldn't it be better to provide the function rpl_malloc yourself? I've
> > looked at the code, and there are many possibilities for passing a zero
> > as the argument of malloc(). On the other hand, if your system's free()
> > happily takes a null pointer, your patch is correct (for your system).
>
> A free(3) which doesn't support being called with a NULL pointer is just
> broken. What malloc does for size 0 is implementation defined.
> Consistent with the spirit of the standard could be a wrapper which
> turns allocations for 0 into allocations of 1, if a program depends on
> that.

On Tru64, malloc(0) returns NULL, which is kinda logical, but probably not 
what everyone expects. There are two soulutions:
a) to make OS specific wrapper-patch library (like separate packet), or
b) netpbm package should by iteslf provide rpl_malloc function

The a) solution would be overall better, because it probably can fix hidden 
errors in other applications too. BUT, then bootstrap needs to check this, 
add special -l<something> flag to LDFLAGS which will replace standard malloc.

This can be done through some special package, like Tru64misc or something 
similar ... :-)

H.