Date: Wed, 28 Sep 2005 00:05:22 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 618 ************************************************** Tuesday 27 September 2005 Number 618 ************************************************** Subjects for today 1 Re: help with dynamic linking : Darwin O'Connor" 2 Re: help with dynamic linking : Stefan.Neis at t-online.de 3 Re: help with dynamic linking : Stefan.Neis at t-online.de 6 Re: help with dynamic linking : Dave Yeo" 7 Re: help with dynamic linking : Stefan.Neis at t-online.de **= Email 1 ==========================** Date: Mon, 26 Sep 2005 12:00:23 -0400 From: "Darwin O'Connor" Subject: Re: help with dynamic linking Stefan.Neis at t-online.de wrote: > Paul Smedley schrieb: > >>Hi All, >>wondering if anyone can help me understand how to do >>dynamic linking >>using gcc? > > > The easy way is to build a static lib (.a or .lib) and run "dllar" on > it, > see the output of plain "dllar" for an explanation on how to use > it (Note that you typically want to use > -libf "INITINSTANCE TERMINSTANCE"). > The complicated version is to look into whatever documentation > on "def" Files, write one, and then use "gcc -Zdll -o something.dll > your-def-File object-Files-you-want-to-link-into-a-Dll". For details > have a look into dllar.cmd. def files aren't very complicated. I believe they are documented in the emx inf files. All you need is this: LIBRARY INITINSTANCE DATA NONSHARED EXPORTS .... **= Email 2 ==========================** Date: Mon, 26 Sep 2005 18:29:54 +0200 (CEST) From: Stefan.Neis at t-online.de Subject: Re: help with dynamic linking Darwin O'Connor schrieb: > def files aren't very complicated. (snipp) > LIBRARY INITINSTANCE > DATA NONSHARED > EXPORTS > > > > > However, for large libraries, generating the list of functions and global variables is not really fun, which is why I prefer to delegate that job to dllar. It's essentially using emxexport(?) to generate those lists, generates the def File and calls gcc -Zdll -o dll-name generated-def-file object-files so why would anybody do all this by hand? Of course, if you need to add ordinals to the functions/variables that are compatible with the ordinals of earlier versions, you _do_ need to manually fix the def file, but normally we shouldn't need to touch it... Regards, Stefan **= Email 3 ==========================** Date: Mon, 26 Sep 2005 17:14:16 +0200 (CEST) From: Stefan.Neis at t-online.de Subject: Re: help with dynamic linking Paul Smedley schrieb: > Hi All, > wondering if anyone can help me understand how to do > dynamic linking > using gcc? The easy way is to build a static lib (.a or .lib) and run "dllar" on it, see the output of plain "dllar" for an explanation on how to use it (Note that you typically want to use -libf "INITINSTANCE TERMINSTANCE"). The complicated version is to look into whatever documentation on "def" Files, write one, and then use "gcc -Zdll -o something.dll your-def-File object-Files-you-want-to-link-into-a-Dll". For details have a look into dllar.cmd. Regards, Stefan **= Email 6 ==========================** Date: Mon, 26 Sep 2005 16:54:40 -0800 From: "Dave Yeo" Subject: Re: help with dynamic linking On Mon, 26 Sep 2005 20:26:00 +0930, Paul Smedley wrote: >Hi All, >wondering if anyone can help me understand how to do dynamic linking >using gcc? > >It's be nice to make use of dlls instead of using static linking :) Surprisingly configure --enable-shared --disable-static often ends up with a DLL. Needs AC_LIBTOOL_WIN32_DLL AC_PROG_LIBTOOL in configure.in and helps to use Andreas port of libtool. Dave **= Email 7 ==========================** Date: Tue, 27 Sep 2005 11:48:12 +0200 (CEST) From: Stefan.Neis at t-online.de Subject: Re: help with dynamic linking Paul Smedley wrote: > It's be nice to make use of dlls instead of using static > linking :) Actually, no, not really. Every application coming with its own version of certain DLLs (which still are limited to 8 letter names) which are mutually incompatible between different apps is causing problems all the time (see discussion about iconv.dll and/or intl.dll, about problems with X11 vs. Innotek versions of jpeg.dll and X11 vs. somebody elses versions of zlib.dll). Using "export by name" for new DLLs would help avoid some of these problems in the future, though. Regards, Stefan