From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Tak Ota Newsgroups: gmane.emacs.devel Subject: Re: Unicode support for the MS Windows clipboard Date: Wed, 28 Jul 2004 09:26:57 -0700 (PDT) Organization: Sony Electronics Inc. Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <20040728.092657.91284256.Takaaki.Ota@am.sony.com> References: <20040727.181258.01371093.Takaaki.Ota@am.sony.com> <41078F73.1060705@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1091032122 1477 80.91.224.253 (28 Jul 2004 16:28:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Jul 2004 16:28:42 +0000 (UTC) Cc: Benjamin.Riefenstahl@epost.de, eliz@gnu.org, handa@m17n.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 28 18:28:25 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BprI1-0002WE-00 for ; Wed, 28 Jul 2004 18:28:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BprLA-0001rI-3W for ged-emacs-devel@m.gmane.org; Wed, 28 Jul 2004 12:31:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BprL2-0001q7-Kx for emacs-devel@gnu.org; Wed, 28 Jul 2004 12:31:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BprL0-0001oR-NK for emacs-devel@gnu.org; Wed, 28 Jul 2004 12:31:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BprL0-0001oO-ID for emacs-devel@gnu.org; Wed, 28 Jul 2004 12:31:30 -0400 Original-Received: from [160.33.82.68] (helo=mail1.fw-sj.sony.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BprH1-0004m3-0A; Wed, 28 Jul 2004 12:27:23 -0400 Original-Received: from mail3.sjc.in.sel.sony.com (mail3.sjc.in.sel.sony.com [43.134.1.211]) by mail1.fw-sj.sony.com (8.12.11/8.12.11) with ESMTP id i6SGQx15007442; Wed, 28 Jul 2004 16:27:04 GMT Original-Received: from localhost ([43.191.18.96]) by mail3.sjc.in.sel.sony.com (8.12.11/8.12.11) with ESMTP id i6SGQxrp003906; Wed, 28 Jul 2004 16:26:59 GMT Original-To: jasonr@gnu.org In-Reply-To: <41078F73.1060705@gnu.org> X-Telephone: +1-858-942-3239 X-Fax------: +1-858-942-9142 X-SnailMail: 16450 West Bernardo Drive MZ7205, San Diego, CA 92127-1804 X-Mailer: Mew-4.0.66 on Emacs-21.3.50.1 (i386-msvc-nt5.1.2600) of 2004-07-23 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:26057 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:26057 Wed, 28 Jul 2004 12:35:15 +0100: Jason Rumney wrote: > > > libc.lib(heapinit.obj) : error LNK2005: __heap_init already defined in > > > temacs1.lib(w32heap.obj) > > > > > > The patch shouldn't have touched those two. The only connection is > > that w32select.c uses "os_subtype", which I is defined in w32heap.c. > > For that w32select.c includes "w32heap.h", that is all the conneciton > > there is. > > > If this is the source of the problem, then moving os_subtype to w32.h > might fix it. But first, we must understand why this problem has > occurred. Is the new implementation of w32select.c using a C library > function that internally mallocs memory using the C library malloc > instead of Emacs' one? Or is it the calls to GlobalAlloc that is causing > this (in which case there is no conflict). I already experimented not to including w32headp.c but locally define enum {OS_OSWIN95 = 1, OS_NT }; and extern int os_subtype; and found the compilation passed but the same link error occurred. Normally (without Benjamin's patch) _heap_init and _heap_term are provided by w32heap.c but the patch somehow pulls in these function from the MS library I suppose. I suspect Jason's theory of hidden malloc maybe the case. I'll continue to investigate. -Tak