Subject: Re: Problems with 2006Q3
To: =?UTF-8?B?SHJ2b2plIEhhYmphbmnEhw==?= <email@example.com>
From: Roland Illig <rillig@NetBSD.org>
Date: 11/03/2006 08:54:42
Hrvoje Habjanić wrote:
> On Thursday 02 November 2006 09:53, Hrvoje Habjanić wrote:
>>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 ...
> 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.