delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2000/05/18/13:51:27

Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
X-Authentication-Warning: hp2.xraylith.wisc.edu: khan owned process doing -bs
Date: Thu, 18 May 2000 12:42:59 -0500 (CDT)
From: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>
To: Kazuhiro Fujieda <fujieda AT jaist DOT ac DOT jp>
cc: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: Can't build the latest snapshot with gcc-2.95.2-1.
In-Reply-To: <s1sr9azhmx6.fsf@jaist.ac.jp>
Message-ID: <Pine.HPP.3.96.1000518123656.15489D-100000@hp2.xraylith.wisc.edu>
MIME-Version: 1.0

On 19 May 2000, Kazuhiro Fujieda wrote:

> I can't build the latest snapshot properly with gcc-2.95.2-1 as
> the following.
> 
> gcc -o mount.exe mount.o -lnetapi32 -ladvapi32
> mount.o(.text+0x29):mount.cc: undefined reference to `muto::~muto(void)'
> /Home/fujieda/cygwin/snap/OBJ/i686-pc-cygwin/winsup/cygwin/libcygwin.a(libccrt0.o)(.text+0x29):libccrt0.cc: undefined reference to `muto::~muto(void)'
> collect2: ld returned 1 exit status
> make[1]: *** [mount.exe] Error 1
> make[1]: Leaving directory `/Home/fujieda/cygwin/snap/OBJ/i686-pc-cygwin/winsup/utils'
> make: *** [utils] Error 2

This is being triggered by the defintion of __mbuf in the inline 
definition of sigthread::init() (sigproc.h). At this point I don't
know where the problem is, but it has to do with the fact that
__mbuf is `static __attribute__((section(".data_cygwin_nocopy")))'.

> As far as I look into the output of `nm libccrt0.o' (attached
> below), the compiler seems to put the unnecessary reference to
> the destructor into the libccrt0.o. Should I use the latest
> snapshot of GCC?

GCC snapshots produce the same behaviour. It's probably a bug in GCC
-- once you start using section attributes and all that, things pretty
hairy in C++.  We need to find a reasonably workaround.

Regards,
Mumit


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019