Mark wrote: > Btw, the main change from 1.06 to 1.08 is pretty much trivial:
> --- Convert-UUlib-1.06/uulib/uucheck.c Thu Mar 3 17:57:31 2005 > +++ Convert-UUlib-1.08/uulib/uucheck.c Sat Dec 16 23:26:16 2006 > @@ -1193,2 +1193,7 @@ > + { > + static uulist uulist_new; > + *unew = uulist_new; /* zero-initialise the structure */ > + } > + > if ((unew->subfname = _FP_strdup (data->subfname)) == NULL) { > and apart from some comments updates and removal of few > (now redundant) assignment this is all there is to it. >> With gcc 4.1.2: >> <...> >> checking for io.h... no >> checking for sys/time.h... yes >> checking for gettimeofday... yes >> checking for tempnam... yes >> checking for chmod... yes >> checking for umask... yes >> checking for mkstemp... yes >> checking for strerror... yes >> checking for stdin... yes >> checking version number... 0.5pl20 >> >> With 3.3.5: >> <...> >> checking for io.h... no >> checking for sys/time.h... yes >> checking for gettimeofday... no >> checking for tempnam... no >> checking for chmod... no >> checking for umask... no >> checking for mkstemp... no >> checking for strerror... no >> checking for stdin... no >> checking for stdarg.h... yes >> checking for varargs.h... no >> checking version number... 0.5pl20 > This seems to be the core of the problem, > the Makefile seems to get it all wrong with gcc 3.3.5. > At the beginning of file Makefile (as just generated > by: "perl Makefile.PL") it should say which version > of MakeMaker created it, like: > # It was generated automatically by MakeMaker version > # 6.31 (Revision: 19606) from the contents of > # Makefile.PL. Don't edit this file, edit Makefile.PL instead. > Maybe experimenting with version of MakeMaker would help. > Mark I was able to compile all versions on a 'stable' system as long as it was running the stable version of libc6. If at any time in the past libc6 was upgraded to 'testing' or 'unstable' then there are apparently issues with the compiler. The fix would be to upgrade the compiler to 'testing' also. In some circumstances installing a newer libc6 will attempt to remove: The following packages will be REMOVED: g++ g++-3.3 giflib3g-dev libc6-dev libstdc++5-3.3-dev libtool locales zlib1g-dev without replacing or upgrading them (I think not having locales would toast a system) and under different circumstances it will not remove them (and will upgrade libc6-dev and locales), but then you have to deal with the apparent side effect of silently breaking the compiler (and possibly even removing the kernel as mentioned before): http://www200.pair.com/mecham/spam/kernel.html I ran: # apt-get -t testing install libstdc++5-3.3-dev Which upgraded: binutils cpp-3.3 g++-3.3 gcc-3.3 gcc-3.3-base libstdc++5 libstdc++5-3.3-dev After this upgrade the compiler worked great. The upgrade to libc6 can occur any time one chooses to install a program from 'testing' or 'unstable' that lists a new version of libc6 as a dependency. Mark, I appreciate the time you spent on this. libc6 compatibility issues are a sore spot with a mixed Debian system. I will sure be glad when Etch is out so we can put this stuff behind us. Gary V ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/