Re: [AMaViS-user] Convert::UUlib 1.08 on Debian Sarge

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?p...rge&CID=DEVDEV
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/...fo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/