Re: bin/37562: new ssh MAC is not working

[Peter Valchev <pvalchev%sightly.net@localhost>]

The following reply was made to PR bin/37562; it has been noted by GNATS.

From: Peter Valchev <pvalchev%sightly.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/37562: new ssh MAC is not working
Date: Wed, 9 Jan 2008 16:47:58 -0800

 Actually this code was tested between little- and big-endian machines as
 well as strict alignment architectures before it was made a part of
 OpenSSH. (It works between my sparc64, alpha, mips64, i386 and even
 tested vax on OpenBSD, and we have received successful reports from
 Linux between different combinations of picky architectures as well).  I
 just verified that this is still the case and there hasn't been a newly
 introduced problem.
 
 I believe it is correct; feel free to show otherwise.  What you are
 seeing is likely not a UMAC bug, but instead a toolchain problem
 introduced with GCC-4 in NetBSD. A similar problem was tracked by
 Thorsten Glaser recently, outlined below.
 
 Do 'gcc -v foo.c' and see whether -lgcc or -lc comes first - probably
 libgcc. The problem is that libgcc and libc contain duplicate symbols,
 and due to -lgcc being passed first to ld/collect2, they are used
 instead of the libc ones. It seems like libgcc has introduced some bugs
 lately, but I don't have a system where to reproduce this right now.
 The misbehaving functions in libgcc are those that override libc/quad
 routines, specifically umoddi3, muldi3, etc. seem to be causing the
 problem.
 
 One way to fix this is to alter the gcc configuration to always
 pass -lc before -lgcc in ld/collect2, so that the libc symbols
 take precedence over the libgcc ones, which is what Thorsten did:
 http://mirbsd.org/cvs.cgi/gcc/gcc/config/mirbsd.h
 +#define LINK_GCC_C_SEQUENCE_SPEC "--start-group %L %G --end-group"
 
 However this may break some things and doesn't really solve the problem,
 rather avoids it. So the best solution would be to fix libgcc and/or
 disable those functions from being built so there is no duplication.
 
 Feel free to double check whether this is the problem in NetBSD (all
 signs seem to point that it is), and/or point to an actual problem in
 UMAC.  If it is the issue described above, chances are it might bite you
 somewhere else, if it hasn't already...
 
 Peter