Re: Problems with 2006Q3

[Roland Illig <rillig%NetBSD.org@localhost>]

Hrvoje Habjanić wrote:
> On Thursday 02 November 2006 09:53, Hrvoje Habjanić wrote:
> [snip]
>
> > Few patches follow.
>
>
> 1. wrapper-sink-osf1.patch 
> Ld on Tru64 doesn't know what to do with "-h <soname>" flag, but it 
> understands "-soname" flag. This patch "fix"es this.

I've committed these two.

> 2. wrapper-buildcmd.patch
> This one is my favorite. In short, Tru64 doent't have strict policy to 
> put "imported" libraries in /usr/local or something similar. They all end up 
> in default places. This include libraries like libjpeg and libz. Of course, 
> those installed in default location are some quite old versions, custom made, 
> needed for normal os operation (gui administration tools). Of course, ld 
> linker first searches default places, and then if it doesn't found library, 
> it searches for it in directories listed in "-L" flags.
> So, i needed a way to modify linker search order to succesufuly compile netpbm 
> package. For Tru 64 ld, to disable default search path, one must include "-L" 
> empty option on command line. Of course, wrapper libraries doesn't allow 
> this - then concatenate anything that comes after "-L"<space>. Instead of 
> complicating with regular expressions, i introduced new flag "-no-std-libs", 
> which bypasses sink wrappers (and others). This, probably, can be done 
> better, but it works for me - all that needs to be done is to put this flag 
> in LDFLAGS directive in mk.conf.

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?

> 4. unzip package
> Authors recently made some changes to crc32.c file, and they broke building of 
> unzipsfx. The problem is that make is first compiling crc32.c for unzip 
> command with USE_ZLIB flag enabled, and later it reuses it form unzipsfx. But 
> that's wrong, because crc32 for unzipsfx must not have USE_ZLIB defined, 
> because unzipsfx doesn't use zlib!! So you get unresolved references ...
> Patch fixes this ...

Committed, thanks.

> 5. png package
> Again, authors assume too much. My os doesn't have gnu malloc. :-) But this is 
> requirement for this package, as can be seen in configure.ac. Unfortunately, 
> authors doesn't provide replacement, so you end up with unresolved 
> rpl_malloc. Quick fix was to remove this requirement, but more permanent 
> solution would be to rpl_malloc be defined somewhere within libpng. I did 
> quick-and-dirty fix. :-)

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).

> 6. netpbm-misc.patch
> This one is big. In short, Tru64 has probably broken snadards.h. Instead of 
> fixing system include file (which could broke a lot of things), i added few 
> #ifdefs in netpbm source files.

Committed, thanks.

Roland