Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <432AF449.2080909@cwilson.fastmail.fm>
Date: Fri, 16 Sep 2005 12:35:21 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Bug in gcc and/or binutils?
References: <000701c5ba80$abb3ba70$e04861cb AT DANNY>
In-Reply-To: <000701c5ba80$abb3ba70$e04861cb@DANNY>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Danny Smith wrote:
> Charles Wilson <cygwin at cwilson dot fastmail dot fm>  wrote:
>>Using .def files turns off the auto-EXport logic (which it should,
>>because if you specify a specific set of exports you don't want binutils
>>adding a few more on its own).
> 
> 
> There seems to be a common misconception that auto-export logic and
> explicit designation of exports are incompatible.
> You can still use --export-all  (to get the auto-export of all defined
> symbols) with a .def file or with __declspec(dllexport).
> 
> eg
> gcc -shared -ofoo.dll foo.def foo.c -Wl,--export-all

Right.  Using a .def file or decorating code with __declspec(dllexport) 
DOES turn off auto-EXport, unless you explicitly turn it back on with 
--export-all.

So, libtool could "solve" the problem by adding --export-all; but *I 
think* libtool only wants to export certain symbols, not all of them. 
So this solution is not the proper one for this particular issue.

> The use of a def file (with --export-all) is useful when you want to
> export all symbols but want special handling of some, say an alias or
> marking a symbol as PRIVATE (exclude from import lib) or NONAME (exclude
> the name of the symbol from the dll's export table), (almost like
> __attribute__((hidden)) Or you may want to add a symbol that is just
> forwarded to another dll. Or you have a function foo() but only want
> the indirect ref __imp__foo visible in the import lib, and not the label:
> 
> foo:
>   jmp * __imp__foo
> 
> so you only export the pointer  by marking as DATA in the def file

Right -- you'd mark it DATA because it IS data:

EXPORTS
   __imp__foo  @1  DATA

exports a pointer.

--
Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/