Mail Archives: cygwin/2003/05/02/00:05:15
Joshua Kwan wrote:
> On Thu, May 01, 2003 at 05:59:32AM +0100, Elfyn McBratney wrote:
>
>>>BTW, I'm using libtool now so *supposedly* building shlibs are fixed.
>
>
> Nope.. :/
>
> libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
> shared libraries
>
> *sigh* This is just a pretty version of the problem I experienced
> before. So... there is NO way to build _true_ shared libraries for
> Cygwin that rely on code from the program that dlopens them? :/
That is correct. Unless we (cygwin) write our own sharedlibrary loader
and format, and stop using DLLs. (I don't want or forsee this, because
there are other ways around the problem)
(1) put the code that must be accessed by both the application and by
the module into a separate DLL (of course, it too must be
self-contained). Then, link both the app and the module against this
extra DLL.
(2) there is a new feature in CVS binutils, where .exe's can have export
tables. (The currently released cygwin binutils doesn't have this, yet,
but it'll come, eventually). Anyway, once you build the .exe with the
export table (using a .def file or __declspec(dllexport) decorators),
you then use dlltool to create an import library (.dll.a) **for the
.exe**. Then, you build the DLL and link against that import lib.
#2 is obviously more cutting edge, and I haven't tested it. But it
should work in principle. There are some hooks in libtool-1.5 to
support this mode, as well, but they haven't been tested (because it's
dependent on a new binutils release).
--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/
- Raw text -