[389] in arla-drinkers
Re: memcpy() problem
daemon@ATHENA.MIT.EDU (Assar Westerlund)
Fri Nov 13 00:19:13 1998
From owner-arla-drinkers@stacken.kth.se Fri Nov 13 05:19:12 1998
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 1099 invoked from network); 13 Nov 1998 05:19:11 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 13 Nov 1998 05:19:11 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id GAA17059
for arla-drinkers-list; Fri, 13 Nov 1998 06:14:50 +0100 (MET)
Received: from assaris.sics.se (assaris.sics.se [193.10.66.108])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id GAA17054
for <arla-drinkers@stacken.kth.se>; Fri, 13 Nov 1998 06:14:47 +0100 (MET)
Received: (from assar@localhost) by assaris.sics.se (8.8.5/8.7.3) id GAA03549; Fri, 13 Nov 1998 06:15:10 +0100 (MET)
To: Frank Cusack <fcusack@iconnet.net>
Cc: arla-drinkers@stacken.kth.se
Subject: Re: memcpy() problem
References: <199811130510.AAA24231@ratbert.iconnet.net>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Assar Westerlund <assar@sics.se>
Date: 13 Nov 1998 06:15:09 +0100
In-Reply-To: Frank Cusack's message of "Fri, 13 Nov 1998 00:10:06 -0500"
Message-ID: <5lemr8maw1.fsf@assaris.sics.se>
Lines: 15
X-Mailer: Gnus v5.5/Emacs 19.34
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
Frank Cusack <fcusack@iconnet.net> writes:
> the readme for arla-0.14 says gcc might not work, and the problem is
> memcpy(). Could this be b/c memcpy() on Solaris doesn't support
> overlapping copies? Although I would guess this would affect Sun's
> C compiler also... hmm unless gcc uses it's own memcpy and Sun's
> uses the library version.
No, it's caused by gcc emitting calls to `memcpy' and there not being
any `memcpy' in the Solaris kernel, only a `bcopy'. (Getting gcc to
generate these references to `memcpy' probably depends on the version
of the gcc and the specific optimization flags used.) If you don't
get any linking problems for `memcpy' when loading the module, it
should just work fine.
/assar
