Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Delivered-To: fixup-cygwin AT cygwin DOT com@fixme
From: "Paul Garceau" <pgarceau AT qwest DOT net>
Organization: New Dawn Productions
To: cygwin AT cygwin DOT com
Date: Mon, 19 Mar 2001 14:48:19 -0800
Subject: Re: Building non-cygwin DLL with cyg-gcc
Reply-to: Paul Garceau <pgarceau AT qwest DOT net>
Message-ID: <3AB61C33.6638.1E7010@localhost>
In-reply-to: <4.3.1.2.20010319122131.0221cdd8@pop.ma.ultranet.com>
References: <002b01c0afdb$6144eea0$3c906520 AT fortin>
X-mailer: Pegasus Mail for Win32 (v3.12c)



On 19 Mar 2001, at 12:32, the Illustrious Larry Hall (RFK Partners, Inc wrote:

> At 01:43 PM 3/18/2001, John Fortin wrote:
> > > There seem to be two methods of building DLLs, the User Guide method
> > > (invoke dlltool multiple times) and the recent Mailing List method
> > > (use the undocumented --output-implib ld switch).  If I do the ML
> > > method, I get
> > >
> > >   > gcc -Wl,--out-implib,file.a -shared -o file.dll file.o
> > >   Cannot export _bss_end__: symbol not defined
> > >   Cannot export _bss_start__: symbol not defined
> > >   Cannot export _data_end__: symbol not defined
> > >   Cannot export _data_start__: symbol not defined
> > >   Creating library file: Packet.a
> > >   collect2: ld returned 1 exit status
> > >   make: *** [main] Error 1
> >
> >I'll ask this again...  Is the above the expected result of using
> >-shared. Why is ld trying to export _bss_* and _data_*. Is it a
> >requirement now to provide a .def file??  The mailing list archives
> >talk a bit around this issue.

	Well, I talk around the .def files because there are different types 
of .def files...it can get rather confusing when speaking about .def 
file differences between using -mno-cygwin and not using the -mno-
cygwin file.  @n decorations are extremely important, and those define 
how a .dll or other type of shared file is created.  How the @n 
decorations are applied can make or break an otherwise reasonable 
linking process.

	There are also some considerations about where the .dll is coming 
from...different .dll sources have different licensing issues...some of 
them are so restrictive that we really can't talk about them...not 
because we are unable to, but because we are limited, in some cases, by 
the .dll licensing supplied with the specific .dll in question...

	I hope this helps to clarify a bit...

	Peace,

		Paul G.


> 
> 
>  From what I understand, you get this if you export everything.  In this
>  
> case, you can end up with things looking for more than is really there.
> A .def file stating exactly what you want to export resolves the
> situation. My description of the details of this issue may be flawed
> (and someone should correct me on these details), but I believe the
> solution I suggest here to this problem is sound.
> 
> 
> 
> Larry
> 
> 
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
> 
> 




Nothing real can be threatened.
    Nothing unreal exists.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple