Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Fri, 16 Sep 2005 17:36:30 +1200 From: Danny Smith Subject: Re: Bug in gcc and/or binutils? To: Cygwin Reply-to: Danny Smith Message-id: <000701c5ba80$abb3ba70$e04861cb@DANNY> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit References: Charles Wilson 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 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 Danny -- 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/