mail/cygwin32

From ian@cygnus.com Tue Nov  3 23:23 EDT 1998
Received: from grande.dcc.unicamp.br (grande.dcc.unicamp.br [143.106.7.8])
	by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id XAA22373
	for <oliva@amazonas.dcc.unicamp.br>; Tue, 3 Nov 1998 23:23:22 -0200 (EDT)
Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1])
	by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id XAA20164
	for <oliva@dcc.unicamp.br>; Tue, 3 Nov 1998 23:23:18 -0200 (EDT)
Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
	by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id UAA13699;
	Tue, 3 Nov 1998 20:25:28 -0500 (EST)
Received: (ian@localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id UAA01678; Tue, 3 Nov 1998 20:25:28 -0500
Date: Tue, 3 Nov 1998 20:25:28 -0500
Message-Id: <199811040125.UAA01678@subrogation.cygnus.com>
From: Ian Lance Taylor <ian@cygnus.com>
To: gvaughan@oranda.demon.co.uk
CC: tanner@gmx.de, oliva@dcc.unicamp.br, gord@trick.fig.org,
        bug-libtool@gnu.org
In-reply-to: <363F3F85.2B31574@oranda.demon.co.uk>
	(gvaughan@oranda.demon.co.uk)
Subject: Re: Inter-library dependencies in libtool
Content-Type: text
X-Content-Length: 3237
Xref: araguaia.dcc.unicamp.br libtool-cygwin32:2
Lines: 69
X-Gnus-Article-Number: 2   Wed Nov  4 01:39:12 1998

   Date: Tue, 03 Nov 1998 17:38:13 +0000
   From: "Gary V. Vaughan" <gvaughan@oranda.demon.co.uk>

   It would seem that the dll code has bitrotted =(O|  Pity.  Ian, do you
   have time/want to fix this, or do you want to pass the torch on?

I no longer have access to a Windows machine, nor do I have all that
much interest in the problem, so I'd say that somebody else had better
pick up the torch.

Incidentally, I believe that DJ Delorie is working on adding DLL
support directly to ld, which will mean that dlltool is no longer
required, and should make it possible to greatly simplify the win32
hacks in dlltool, perhaps even simply using the standard GNU ld code.

   Shouldn't libtool notice that it is running on cygwin32 and pass the
   -no-undefined option by itself?  It seems to go against the raison
   d'etre for libtool to force the Makefile developer to figure this out...

This kind of goes to the heart of libtool.  libtool wants to present a
particular interface for using shared libraries.  In order to do this,
it assumes that the system supports certain capabilities.  One of
those is that the system can support undefined symbols in shared
libraries.

That means that on systems which do not permit shared libraries to
have undefined symbols--AIX and Windows--libtool doesn't really work.

The --no-undefined option is a hack which tells libtool that the
shared library has special characteristics which permit libtool to
create a shared library on AIX or Windows, or any other supported
platform.

I think the general idea is that you should use the --no-undefined
option whenever possible.  If you do, you will be able to create
shared libraries on AIX and Windows.  If you do not or can not, you
will not be able to create them.

libtool should not add a --no-undefined option itself.  If it used
that option inappropriately, then building the shared library would
fail.  Instead, libtool users should always use --no-undefined if they
can.

Of course, there are problems.  For example, in the GNU binutils, I
can arrange matters such that --no-undefined will work on Windows, but
to do so I have to link various libraries together and I have to link
against special Windows system libraries.  So I do that, which means
that I have to change the options I pass to libtool based on the
system.

In other words, the interface which libtool presents is deficient.  It
does not successfully hide the system on which it is running, and it
forces the code which calls libtool to make adjustments.

I doubt there is any wholly acceptable solution here.  The only
workable one I can see would be to effectively enhance Windows and AIX
shared libraries such that they support creating shared libraries with
undefined symbols.  On Windows, this could be done by doing the link
once, checking for undefined symbols, creating little stub routines
for those symbols which track down the symbols in some other open DLL,
compiling those stubs, and linking them into the DLL.  Perhaps
something similar is possible on AIX.

Of course even that will not make Windows DLLs identical to ELF shared
libraries.  ELF shared libraries permit the main program to override a
symbol in the shared library, and Windows DLLs do not.

Ian

When libtool links DLLs, it strips some command line switches. It's probably
the case that this is ok for most situations. However, this potentially breaks
Mingw32 support in the Cygwin environment.

In order to get Mingw32 support in Cygwin, the compiler must be invoked with
the -mno-cygwin switch. If libtool strips this switch out during the link
process, the resulting binary will get linked with the wrong import libraries.

The following is a small example. I've edited the output a bit for
readability. When I send this email, long lines will get broken up, so it
still might be a bit difficult to read.

-------------------------

$ libtool --version
ltmain.sh (GNU libtool) 1.3.3 (1.385.2.181 1999/07/02 15:49:11)


$ cat xx.c

extern __declspec(dllexport) int func(void);

int func()
{
}


$ libtool --mode=compile gcc -mno-cygwin -c xx.c
mkdir .libs
gcc -mno-cygwin -c  -DPIC xx.c -o .libs/xx.lo
mv -f .libs/xx.lo xx.o
ln -s xx.o xx.lo

$ libtool --mode=link gcc -mno-cygwin -o libxx.la xx.lo \
	-version-info 0:0:0 -no-undefined -rpath /usr/local/lib

rm -fr .libs/libxx.la .libs/libxx.* .libs/libxx.*

generating symbol list for `libxx.la'

test -f .libs/libxx-0-0-0.dll-ltdll.c || sed -e "/^# \/\* ltdll\.c starts here
\*\//,/^# \/\* ltdll.c ends here \*\// { s/^# //; p; }" -e d <
/usr/local/bin/libtool > .libs/libxx-0-0-0.dll-ltdll.c

 test -f .libs/libxx-0-0-0.dll-ltdll.o || (cd .libs && gcc -c
libxx-0-0-0.dll-ltdll.c)

 dlltool --export-all --exclude-symbols
DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12 --output-def
.libs/libxx-0-0-0.dll-def .libs/libxx-0-0-0.dll-ltdll.o  xx.o

 sed -e "1,/EXPORTS/d" -e "s/ @ [0-9]* ; *//" < .libs/libxx-0-0-0.dll-def >
.libs/libxx.exp

echo EXPORTS > .libs/libxx-0-0-0.dll-def

 _lt_hint=1; for symbol in `cat .libs/libxx.exp`; do echo " $symbol @
$_lt_hint; " >> .libs/libxx-0-0-0.dll-def; _lt_hint=`expr 1 + $_lt_hint`; done

 test -f .libs/libxx-0-0-0.dll-ltdll.c || sed -e "/^# \/\* ltdll\.c starts
here\*\//,/^# \/\* ltdll.c ends here \*\// { s/^# //; p; }" -e d <
/usr/local/bin/libtool > .libs/libxx-0-0-0.dll-ltdll.c

 test -f .libs/libxx-0-0-0.dll-ltdll.o || (cd .libs && gcc -c
libxx-0-0-0.dll-ltdll.c)


gcc -Wl,--base-file,.libs/libxx-0-0-0.dll-base -Wl,--dll -nostartfiles -Wl,-e,
__cygwin_dll_entry@12 -o .libs/libxx-0-0-0.dll .libs/libxx-0-0-0.dll-ltdll.o
xx.o

 dlltool --as=as --dllname libxx-0-0-0.dll --exclude-symbols
DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12 --def
.libs/libxx-0-0-0.dll-def --base-file .libs/libxx-0-0-0.dll-base --output-exp
.libs/libxx-0-0-0.dll-exp

 gcc -Wl,--base-file,.libs/libxx-0-0-0.dll-base
.libs/libxx-0-0-0.dll-exp -Wl,--dll -nostartfiles -Wl,-e,__cygwin_dll_entry@12
 -o .libs/libxx-0-0-0.dll .libs/libxx-0-0-0.dll-ltdll.o  xx.o

 dlltool --as=as --dllname libxx-0-0-0.dll --exclude-symbols
DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12 --def
.libs/libxx-0-0-0.dll-def --base-file .libs/libxx-0-0-0.dll-base --output-exp
.libs/libxx-0-0-0.dll-exp

 gcc
.libs/libxx-0-0-0.dll-exp -Wl,--dll -nostartfiles -Wl,-e,__cygwin_dll_entry@12
 -o .libs/libxx-0-0-0.dll .libs/libxx-0-0-0.dll-ltdll.o  xx.o

(cd .libs && rm -f libxx.a && ln -s libxx-0-0-0.dll libxx.a)

dlltool --as=as --dllname libxx-0-0-0.dll --def
.libs/libxx-0-0-0.dll-def --output-lib .libs/libxx.a

creating libxx.la

(cd .libs && rm -f libxx.la && ln -s ../libxx.la libxx.la)

---------------

Notice how the 'gcc' lines do not contain the -mno-cygwin switch. This switch
should not get stripped.

Jon Leichter
jon@symas.com


"Gary V. Vaughan" wrote:
> 
> On Wed, Aug 30, 2000 at 10:51:36AM -0400, Charles Wilson wrote:
> > No, it can't.  Currently, libtool itself doesn't support *building*
> > dlls.
> 
> Ouch.  Yes it does.  I added support around Christmas 1998, and have
> been maintaining it ever since.

Thanks for the correction.

> 
> Yes it does.  And provided your libraries don't trip over the stupid
> dll limitation of "to export a non-function symbol you must edit your
> sources", it works easily.  Even if you do export data symbols,
> libtool woll build and link against a dll for you (even generating an
> import lib along the way).
> 
> Unfortunately libtool was developed for Unix and assumes a featureful
> shared library architecture, which doesn't map very easily onto win32
> dll's.
> 
> I will be able to simplify the dll build process a little when DJ's
> patches to binutils arrive in a cygwin release (did this happen in
> 1.1? I have been so busy with m4 that I only upgraded from b20.1 a few
> weeks ago).

They landed in binutils-20000625, and were finetuned/tweaked to a fairly
stable point by binutils-20000722 (the current version in /latest).

Also, there were a few additions that changed ld's default search order
for libraries:
  -Bstatic -lfoo  : 
    looks for libfoo.a
  -Bdynamic -lfoo : 
    looks for libfoo.dll.a (default name for an import lib)
         then foo.dll.a    (alt. name for an import lib)
         then libfoo.dll   (link directly to a dll)
         then foo.dll      (ditto, alt. name)
     finally, libfoo.a     (fall back to static lib)

The spec file for gcc (as of 2.95.2-2) changed so that:
   gcc -static   calls 'ld -Bstatic'
   gcc           calls 'ld -Bdynamic'

Finally, 'gcc -shared' will build a dll, but you need to pass linker
options like '-Wl,--out-implib=libfoo.dll.a' explicitly. 

FWIW, all of the (non-libtool) libraries I've dll-ized do not use
dlltool at all, and rely only on gcc (and ld, indirectly).

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
From gary  Tue Oct  3 18:51:55 2000
Return-Path: <cygwin-return-16563-gvaughan=oranda.demon.co.uk@sources.redhat.com>
Received: from pop3.mail.demon.net
	by localhost with POP3 (fetchmail-5.3.4)
	for gary@localhost (single-drop); Tue, 03 Oct 2000 18:51:55 +0100 (BST)
Received: from punt-2.mail.demon.net by mailstore
          for gvaughan@oranda.demon.co.uk id 970581289:20:22249:24;
          Tue, 03 Oct 2000 13:54:49 GMT
Received: from sourceware.cygnus.com ([205.180.83.71]) by punt-2.mail.demon.net
           id aa2022220; 3 Oct 2000 13:54 GMT
Received: (qmail 29977 invoked by alias); 3 Oct 2000 13:52:38 -0000
Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-gvaughan=oranda.demon.co.uk@sources.redhat.com>
List-Subscribe: <mailto:cygwin-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin@sources.redhat.com>
List-Help: <mailto:cygwin-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner@sources.redhat.com
Delivered-To: mailing list cygwin@sources.redhat.com
Received: (qmail 29933 invoked from network); 3 Oct 2000 13:52:34 -0000
Received: from mumnunah.cs.mu.oz.au (203.19.244.130)
  by sourceware.cygnus.com with SMTP; 3 Oct 2000 13:52:34 -0000
Received: from murlibobo.cs.mu.OZ.AU (murlibobo.cs.mu.OZ.AU [128.250.29.17]) by mumnunah.cs.mu.OZ.AU with ESMTP
        id AAA23121; Wed, 4 Oct 2000 00:52:14 +1100 (EST)
Received: (from fjh@localhost) by murlibobo.cs.mu.OZ.AU (8.8.5/8.7.3) id AAA11289; Wed, 4 Oct 2000 00:52:13 +1100 (EST)
Date: Wed, 4 Oct 2000 00:52:13 +1100
From: Fergus Henderson <fjh@cs.mu.oz.au>
To: "Gary V. Vaughan" <gvv@techie.com>, cygwin@sources.redhat.com,
        cgf@cygnus.com
Subject: Re: linking against shared libraries
Message-ID: <20001004005212.A9274@murlibobo.cs.mu.OZ.AU>
References: <012a01c02033$936effc0$f7c723cb@lifelesswks> <20000917010735.G606@demon.co.uk> <20000916234420.A23827@cygnus.com> <20000917122440.I606@demon.co.uk> <20000917122837.A24997@cygnus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.1i
In-Reply-To: <20000917122837.A24997@cygnus.com>; from Chris Faylor on Sun, Sep 17, 2000 at 12:28:37PM -0400
Status: RO
Content-Length: 2625
Lines: 51

On 17-Sep-2000, Chris Faylor <cgf@cygnus.com> wrote:
> On Sun, Sep 17, 2000 at 12:24:40PM +0100, Gary V. Vaughan wrote:
> >If you are interested, I will add an entry to my TODO list to see if I
> >can take some of the nicities from the libtldl LoadLibrary wrapper
> >code and apply them to the Cygwin LoadLibrary wrapper?  (Automatic `_'
> >prefixing for example).
> 
> Is this a characteristic of normal linux/UNIX dlsym?

AFAIK, Unix systems that support dlopen() don't prefix C symbol
names with `_' when compiling them to assembler in the first place,
so the issue is moot.  At least this is the case on Solaris (2.7),
Linux (>= libc6), and OSF1 (3.2 ), which are the systems that
I have easily available right now.  dlopen() originated on Solaris,
according to the Linux man page.

On systems such as Cygwin which do prefix C names with `_' when
compiling to assembler, whether dlopen() should prefix the name with an
underscore depends on whether the name that the user is trying to look
up is an assembly name or a C name.  If it's a C name, then it's right
for dlopen() to prefix the name with an underscore, to match what the
C compiler does, but if it's an assembly name, then doing that would
be wrong.  Unfortunately the interface to dlopen() provides the
dlopen() implementation with no clues as to which one the user meant.
The documentation for dlopen() says that the argument is the "symbol
name", which is ambiguous, but could be read as implying that it is
supposed to be the assembly name.  However, in practice most uses of
dlopen() tend to be passing C names rather than assembler names.

Probably most uses of dlopen() are for C names, and so inserting
the prefix would work well in most cases.  However, inserting the
prefix would also make it impossible to look up assember names that
don't start with underscore using dlopen().

It's a bit like the issue of text-versus-binary:
the original unix-only interface didn't need to distinguish
between the different cases (text/binary or C/asm/whatever),
but in the Windows environment, you do need to make such
distinctions.  So some programs will need source modifications.
The best you can do is to choose the default carefully,
and make it easy to override the default for programs for which
the default is not appropriate.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

On Sun, Sep 03, 2000 at 01:34:23AM -0400, Charles Wilson wrote:
> "Gary V. Vaughan" wrote:
> 
> > > Now, suppose that the png folks release a newer version, say png-2.1.x
> > > that exposes some additional features, but is backwards compatible with
> > > png-2.0.x.  Great.  You build it, but create:
> > >
> > >   libpng31.dll.a (embeds the name libpng31.dll.a)
> > >   libpng.dll.a -> libpng31.dll.a
> > >   libpng3.dll (replaces the old version (*))
> > 
> > I don't think we need anything more than
> > 
> >     a replacement libpng3.dll
> 
> Not so.  Remember, libpng-2.1.x can include additional functions that
> were not included by libpng-2.0.x, as long as it includes all of the
> 'old' functions/vars without modification.  So, you need to update the
> import lib as well as the dll, so that new packages that use the
> additional functions will work.

Oops.  I hadn't thought of that.  Good point.

> > Otherwise we are still in violent agreement.
> 
> I agree.

=)O|

> > > > Maybe Cygwin should put all of it's libtool built libraries (or any
> > > > others that are correctly versioned w.r.t the runtime loader) into a
> > > > single directory that is near the front of the default path.  /usr/lib
> > > > seems like a good place.
> > >
> > > That's part of my 'easy' solution above.  It may fix the cygwin problem,
> > > but the requirement is not nice to native apps or other unix-on-win
> > > emulations that the user may have.
> > >
> > > Relying on 'get dll's from same dir as .exe' works -- but only if EVERY
> > > cygwin exe and EVERY cygwin dll are piled into the same dir.
> > 
> > Can't we assume that the native dll's we rely on are outside cygwin's
> > control and can be relied upon to be managed by the operating system
> > (I'm thinking of stuff in the SYSTEM directory), and that non-cygwin
> > libraries (such as Pauls pw dlls) will not be installed into the
> > cygwin binary search path?  In which case I think it is okay to
> > install all cygwin dlls and import libs to /usr/lib, making sure that
> > cygwin.bat (or any other cygwin startup methods) put /usr/lib first in
> > $PATH.  
> 
> this works for the 'sandbox user' -- Michael Ring's 'user 1' in this
> message:
>    http://sources.redhat.com/ml/cygwin/2000-08/msg01241.html
> 
> It doesn't work for Michael's 'user 2' -- the guy who normally runs in
> cmd.exe/command.com, but relies on cygwin commands every once in a
> while.  He doesn't use bash, but likes the cygwin-perl or grep every
> once and a while.  User 2 will have the cygwin directories somewhere in
> her path -- but not necessarily first.

We could tell these people to put C:/cygwin/usr/bin at the front of
their PATH...

> > Does cygwin ld use -rpath yet?  
> 
> I don't think so.  -rpath is something that ld.so uses; Windows doesn't
> have ld.so. Windows *always* loads dll's according to the following
> search order:
>    current directory
>    app's load directory
>    global executable search path
> 
> The only two exceptions I know of are:
> 
>   1) In Win2K, if there is a file called 'app.exe.local' in the same
> directory as app.exe, then all dll's will be loaded from the app's load
> directory -- even if explicitly dlopened() with an absolute path that
> points elsewhere.  the .local. may also override the 'current directory'
> part of the search order listed above, but I'm not sure.

Holy cr@p! What happened to simplicity?  If Bill has decided that he
can't understand how to write a decent shared library system, and
want's to relegate dll's to LoadLibrary() objects, why doesn't he just
say so?  Wouldn't it be easier to statically link a Win2k program that
twiddle about with all this .local mess?

>   2) You can put something called 'AppPath' in the registry, which will
> influence the directories that are searched. I don't know where in the
> list above that the directories listed in the 'AppPath' key are
> inserted.

This sounds promising.  I'll see if I can find any details on it.

> > I am prepared to work on having libtool do the right thing as far
> > as possible. 
> 
> What was the right thing, again?  :-)

Based on our conversation so far:

  * When building a libtool (.la) library, create libfoo.la,
    libfoo<iface>.dll, libfoo.dll.a and libfoo.a, where:
      - <iface> is the earliest fully supported interface number
      - libfoo.dll.a is the import library for libfoo<iface>.dll
      
  * When installing a libtool (.la) library:
      - libfoo.la goes to $prefix/lib
      - libfoo<iface>.dll goes to $prefix/bin
      - libfoo.dll.a goes to $prefix/lib
      - libfoo.a goes to $prefix/lib
      
  * When linking against libfoo.la
      - use libfoo.dll.a unless -static or -all-static 
      - otherwise use libfoo.a

  * When linking against -lfoo
      - if libfoo.la is found, behave as above
      - else let ld (or gcc) do its thing

Which is especially cool, because I don't think I need to worry about
dealing with direct linkage to dlls (I can just punt and let gcc/ld do
the hard work) which removes a whole pile of spaghetti where I had to
cope with compiling the impgen code correctly in cross compilation
environments!

> > By default libtool always searches for a dll to link against and
> > generates the implib on the fly if a suitable one is found.

This won't be necessary under the new scheme =)O|

> There are occaisions where you want to link to an import lib in
> preference to a dll -- for instance, libcygwin.a is an import lib, but
> contains initializer code and actual function implementations for some
> functions that are not included in the dll itself.  If you attempt to
> link directly to cygwin1.dll, the link fails because those things are
> missing from the virtual on-the-fly implib.

I didn't know about that.  Thanks.

> But where do you put the dll?  It has to go into the executable PATH so
> that the windows loader can find it.  Do you copy it into /usr/lib, so
> that the default ld search path will find it?  Do you add /usr/bin to
> the linktime library search path (-L/usr/bin)?  Perhaps a symlink in
> /usr/lib, pointing to /usr/bin/libfoo.dll is all you need. 
> 
> However!!! Ld uses the following library name search order when hunting
> for -lfoo:
> 
>   libfoo.dll.a
>   foo.dll.a
>   libfoo.a  <<<< NOTE!!
>   libfoo.dll
>   foo.dll

Or that.  Thanks again!  Libtool already provides --disable-static if
the user wants to build and install only the dll parts of the library.

For this to work (that is, in order for me to be able to punt to gcc/ld
in the majority of cases) I must generate dll names that will be
found, so the cygfoo.dll idea is out (Sorry Paul!).

Although this doesn't help ``User 2'' very much, he is no worse off
than before if I change libtool's behaviour in this way.  Here's a
thought:  For each dll using application linked, I could have libtool
install a .bat script to C:/cygwin/launch (or similar) which would set
the PATH environment correctly for that application.  As long as
``User 2'' has the launch directory higher in his PATH than the actual
binary directory, this would guarantee correct dll selection.

This would give ``User 1'' many of the advantages shared libraries
offer on Unix, without sinking into DLL Hell.  Assuming that everyone
buys into it.  The only reason shared libraries work properly on Unix
is that everyone has to agree to conform to the runtime loader's
versioning scheme -- so don't give some excuse about ``if we don't
want to change the core cygwin dll's to conform this won't work''.  On
my linux box, I can move my libc around or drop several incompatible
versions of libc into my filesystem, and my applications will stop
loading the intended libraries too.  No surprises there!

Cheers,
	Gary.
-- 
  ___              _   ___   __              _         mailto: gvv@techie.com
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       gary@gnu.org 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
On Sun, Sep 03, 2000 at 04:39:51PM -0300, Alexandre Oliva wrote:
> On Sep  3, 2000, "Gary V. Vaughan" <gvv@techie.com> wrote:
> 
> >   * When installing a libtool (.la) library:
> >       - libfoo.la goes to $prefix/lib
> >       - libfoo<iface>.dll goes to $prefix/bin
> >       - libfoo.dll.a goes to $prefix/lib
> >       - libfoo.a goes to $prefix/lib
>       
> Nope.  libfoo.la goes wherever -rpath specified when the library was
> created; it should be the same directory that is specified at install
> time.  This is often $(libdir), but it doesn't have to be.
> 
> I don't know how to arrange for an additional directory (bindir) to
> be specifiable without introducing an additional command-line option.
> Remember, libtool doesn't know about prefix, libdir or bindir, it just
> knows about what it's given in the command line.

Hmm.  I hadn't thought of that.  Still, at least the principle of the
thing is right now, I think...

Cheers,
	Gary.
-- 
  ___              _   ___   __              _         mailto: gvv@techie.com
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       gary@gnu.org 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc

There's an easier way -- one command!  'gcc -shared' will create a dll
for you.  Just do:

$(BASE)=foo

  gcc -shared -o cyg$(BASE).dll -Wl,--out-implib=lib$(BASE).dll.a \
    -Wl,--export-all -Wl,--enable-auto-image-base \
    -Wl,--output-def=cyg$(BASE).def $(OBJS)

Grab any of the packages in the 'contrib' directory and look an the
makefiles (you might need to do a minimal 'configure' first, to
customize the Makefile for cygwin before using it as a model)

--Chuck

Jrgen Schuck wrote:
> 
> I'm not sure about the kind of object that 'gcc -shared'
> produces. But I think it won't be what you might expect.
> In Windows shared sobjects are DLL's. You probably will
> have to convert your Makefiles to cproduce DLL's instead
> of UNIX-style .so files.
> 
> I did the same task when porting a TCL-extension from
> UNIX to Cygwin. The Makefile (SVR4) changes from
> 
> libTclDM20.so:
>         ld -G -o $@ $(OBJS)
> 
> to
> 
> LOAD      = TclDM20
> DEF       = $(LOAD).def
> BAS       = $(LOAD).base
> EXP       = $(LOAD).exp
> $(DLL): $(OBJS)
>         echo EXPORTS >$(DEF)
>         nm $+ | grep '^........ [T] _' | sed 's/[^_]*_//' >>$(DEF)
>         $(LD) --base-file $(BAS) -dll -o $@ $+ -e _dll_entry@12 \
>                                 -L`dirname \`gcc -print-file-name=libgcc.a\`` \
>                                 $(LIBS) -lgcc -lcygwin -lkernel32 -lgcc
>         dlltool --as=as -dllname $@ --def $(DEF) \
>                                         --base-file $(BAS) --output-exp $(EXP)
>         $(LD) --base-file $(BAS) $(EXP) -dll -o $@ $+ -e _dll_entry@12 \
>                                 -L`dirname \`gcc -print-file-name=libgcc.a\`` \
>                                 $(LIBS) -lgcc -lcygwin -lkernel32 -lgcc
>         dlltool --as=as -dllname $@ --def $(DEF) \
>                                         --base-file $(BAS) --output-exp $(EXP)
>         $(LD) $(EXP) -dll -o $@ $+ -e _dll_entry@12 \
>                                 -L`dirname \`gcc -print-file-name=libgcc.a\`` \
>                                 $(LIBS) -lgcc -lcygwin -lkernel32 -lgcc
> 
> For further information see
> http://sources.redhat.com/cygwin/docs.html,
> section "Writing DLLs". Reading these docs you
> will find two further modules: dll_init.c and
> dll_fixup.c. I didn't put them into my DLL because
> the resulting DLL crashes the TCL-interpreter.
> 
> Furthermore I found it very helpful to take a
> look into the Makefiles of the DLL-generating
> packages of the Cygwin-distribution: tcl, wish
> and tix.
> 
> Jrgen Schuck
> PCM-Kundenbetreuung
> Business Unit Information
> _________________________________________________
> MATERNA GmbH Information & Communications
> Vosskuhle 37 * 44141 Dortmund
> Tel.: 0231 - 5599 - 191 *  Fax: -272
> Handy: 0172 - 23 70 148  * http://www.materna.de
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
From gary  Tue Oct 10 18:50:22 2000
Return-Path: <cygwin-return-16847-gvaughan=oranda.demon.co.uk@sources.redhat.com>
Received: from pop3.mail.demon.net
	by localhost with POP3 (fetchmail-5.3.4)
	for gary@localhost (single-drop); Tue, 10 Oct 2000 18:50:22 +0100 (BST)
Received: from punt-2.mail.demon.net by mailstore
          for gvaughan@oranda.demon.co.uk id 971135226:20:06380:2;
          Mon, 09 Oct 2000 23:47:06 GMT
Received: from sourceware.cygnus.com ([205.180.83.71]) by punt-2.mail.demon.net
           id aa2005552; 9 Oct 2000 23:46 GMT
Received: (qmail 16236 invoked by alias); 9 Oct 2000 23:46:45 -0000
Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-gvaughan=oranda.demon.co.uk@sources.redhat.com>
List-Subscribe: <mailto:cygwin-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin@sources.redhat.com>
List-Help: <mailto:cygwin-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner@sources.redhat.com
Delivered-To: mailing list cygwin@sources.redhat.com
Received: (qmail 16211 invoked from network); 9 Oct 2000 23:46:43 -0000
Received: from mail.ee.gatech.edu (130.207.230.10)
  by sourceware.cygnus.com with SMTP; 9 Oct 2000 23:46:43 -0000
Received: from ece.gatech.edu (s02-pm03.gatech.campuscwix.net [168.14.1.69])
	by mail.ee.gatech.edu (8.11.0/8.11.0) with ESMTP id e99NkTO15440;
	Mon, 9 Oct 2000 19:46:30 -0400 (EDT)
Message-ID: <39E259A7.CBAD325F@ece.gatech.edu>
Date: Mon, 09 Oct 2000 19:49:59 -0400
From: Charles Wilson <cwilson@ece.gatech.edu>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin@sourceware.cygnus.com
Subject: Re: AW: Linking Dynamic Libraries
References: <004501c031f0$10478ad0$0d33028b@zapperlot.materna.de> <39E1CC08.F475851F@ece.gatech.edu> <39E2468B.BFDD3AB7@ihug.co.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 5252
Lines: 189

You still need to worry about things like __declspec(dllexport) and
__declspec(dllimport).  Here's a patch for your files.  

(Yes, you are correct; the option is '--export-all-symbols' not
'--export-all')

As far as documentation, there's the mailing list, and 'ld --help' and
Mumit's (really out-of-date) dll-helpers packaqe at
http://www.xraylith.wisc.edu/~khan/software/gnu-win32/dllhelpers.html. 
Would you like to update that package for the current capabilities of
ld/gcc ?  Mumit's tutorial is heavily 'dlltool' based, rather than 'gcc
-shared' or 'ld' based.

NOTE 1: I had to remove "-Wl,--export-all-symbols" from the options;
with export-all I got a stack dump even with my other changes. I'm not
sure why.

NOTE 2: I used the extension '.dll.a' for the import library; cygwin's
linker will search for 'libfoo.dll.a' in preference to 'libfoo.a';
libfoo.a is assumed to be a static library (although the linker will use
libfoo.a if .dll.a is not found)

--Chuck


diff -u demo-orig/Makefile demo/Makefile
--- demo-orig/Makefile  Mon Oct  9 19:34:15 2000
+++ demo/Makefile       Mon Oct  9 19:45:10 2000
@@ -3,7 +3,7 @@
 EXENAME = demo
 EXEOBJ = demo.o
 CPLUS = g++ -W -Wall -Werror
-LINKDLL = g++ -shared -Wl,--export-all -Wl,--enable-auto-image-base
+LINKDLL = g++ -shared -Wl,--enable-auto-image-base
 LINKEXE = g++ -L.
 
 .DELETE_ON_ERROR:
@@ -13,13 +13,16 @@
 all: $(DLLNAME).dll $(EXENAME)
 
 clean:
-       rm -f $(DLLOBJ) $(DLLNAME).dll lib$(DLLNAME).a $(EXEOBJ)
$(EXENAME).exe
+       rm -f $(DLLOBJ) $(DLLNAME).dll lib$(DLLNAME).dll.a $(EXEOBJ)
$(EXENAME).exe
 
 %.o: %.cpp
        $(CPLUS) -c $< -o $@
 
+$(DLLOBJ): $(DLLOBJ:.o=.cpp)
+       $(CPLUS) -DBUILD_DLL -c $< -o $@
+
 $(DLLNAME).dll: $(DLLOBJ)
-       $(LINKDLL) $(DLLOBJ) -o $(DLLNAME).dll
-Wl,--out-implib=lib$(DLLNAME).a
+       $(LINKDLL) $(DLLOBJ) -o $(DLLNAME).dll
-Wl,--out-implib=lib$(DLLNAME).dll.a
 
 $(EXENAME): $(EXEOBJ) $(DLLNAME).dll
        $(LINKEXE) $(EXEOBJ) -l$(DLLNAME) -o $(EXENAME)
diff -u demo-orig/foo.hpp demo/foo.hpp
--- demo-orig/foo.hpp   Mon Oct  9 19:35:58 2000
+++ demo/foo.hpp        Mon Oct  9 19:35:50 2000
@@ -3,7 +3,12 @@
 
 #include <string>
 
-extern std::string global_mangle(const std::string& source);
-
+#ifdef BUILD_DLL
+#define FOO_EXPORT __declspec(dllexport)
+#else
+#define FOO_EXPORT __declspec(dllimport)
 #endif
 
+extern FOO_EXPORT std::string global_mangle(const std::string& source);
+
+#endif

Ross Smith wrote:
> 
> "Charles S. Wilson" wrote:
> >
> > There's an easier way -- one command!  'gcc -shared' will create a dll
> > for you.  Just do:
> >
> > $(BASE)=foo
> >
> >   gcc -shared -o cyg$(BASE).dll -Wl,--out-implib=lib$(BASE).dll.a \
> >     -Wl,--export-all -Wl,--enable-auto-image-base \
> >     -Wl,--output-def=cyg$(BASE).def $(OBJS)
> 
> I can't get this to work. Whenever I link with the import lib produced
> this way, the resulting program crashes with a STATUS_ACCESS_VIOLATION.
> (See attached code.) I don't even need to call any of the DLL functions
> to trigger it -- just linking with -lfoo makes it unworkable. What am I
> doing wrong?
> 
> And where is all this stuff documented anyway? The ld docs mention
> --export-all-symbols (not --export-all), but not any of the others.
> 
> -------------------- cut here --------------------
> 
> // demo.cpp
> 
> #include "foo.hpp"
> #include <iostream>
> #include <string>
> 
> int main() {
>   std::string thing("thing");
>   std::cout << thing << std::endl;
> //  std::cout << global_mangle(thing) << std::endl;
>   return 0;
> }
> 
> -------------------- cut here --------------------
> 
> // foo.hpp
> 
> #ifndef FOO_HEADER
> #define FOO_HEADER
> 
> #include <string>
> 
> extern std::string global_mangle(const std::string& source);
> 
> #endif
> 
> -------------------- cut here --------------------
> 
> // foo.cpp
> 
> #include "foo.hpp"
> 
> std::string global_mangle(const std::string& source) {
>   return source + "_global";
> }
> 
> -------------------- cut here --------------------
> 
> // Makefile
> 
> DLLNAME = foo
> DLLOBJ = foo.o
> EXENAME = demo
> EXEOBJ = demo.o
> CPLUS = g++ -W -Wall -Werror
> LINKDLL = g++ -shared -Wl,--export-all -Wl,--enable-auto-image-base
> LINKEXE = g++ -L.
> 
> .DELETE_ON_ERROR:
> 
> .PHONY: all clean
> 
> all: $(DLLNAME).dll $(EXENAME)
> 
> clean:
>     rm -f $(DLLOBJ) $(DLLNAME).dll lib$(DLLNAME).a $(EXEOBJ)
> $(EXENAME).exe
> 
> %.o: %.cpp
>     $(CPLUS) -c $< -o $@
> 
> $(DLLNAME).dll: $(DLLOBJ)
>     $(LINKDLL) $(DLLOBJ) -o $(DLLNAME).dll
> -Wl,--out-implib=lib$(DLLNAME).a
> 
> $(EXENAME): $(EXEOBJ) $(DLLNAME).dll
>     $(LINKEXE) $(EXEOBJ) -l$(DLLNAME) -o $(EXENAME)
> 
> demo.o: demo.cpp foo.hpp
> foo.o: foo.cpp foo.hpp
> 
> -------------------- cut here --------------------
> 
> --
> Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
> ========================================================================
> "C++ is to programming as sex is to reproduction. Better ways might
> technically exist but they're not nearly as much fun." -- Nikolai Irgens
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

From gary  Wed Oct 11 18:38:50 2000
Return-Path: <cygwin-return-16974-gvaughan=oranda.demon.co.uk@sources.redhat.com>
Received: from pop3.mail.demon.net
	by localhost with POP3 (fetchmail-5.3.4)
	for gary@localhost (single-drop); Wed, 11 Oct 2000 18:38:50 +0100 (BST)
Received: from punt-1.mail.demon.net by mailstore
          for gvaughan@oranda.demon.co.uk id 971256552:10:18423:4;
          Wed, 11 Oct 2000 09:29:12 GMT
Received: from sourceware.cygnus.com ([205.180.83.71]) by punt-1.mail.demon.net
           id aa1018296; 11 Oct 2000 9:29 GMT
Received: (qmail 10937 invoked by alias); 11 Oct 2000 09:28:33 -0000
Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-gvaughan=oranda.demon.co.uk@sources.redhat.com>
List-Subscribe: <mailto:cygwin-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin@sources.redhat.com>
List-Help: <mailto:cygwin-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner@sources.redhat.com
Delivered-To: mailing list cygwin@sources.redhat.com
Received: (qmail 10909 invoked from network); 11 Oct 2000 09:28:30 -0000
Received: from web6405.mail.yahoo.com (128.11.22.153)
  by sourceware.cygnus.com with SMTP; 11 Oct 2000 09:28:30 -0000
Message-ID: <20001011092829.19377.qmail@web6405.mail.yahoo.com>
Received: from [203.97.2.247] by web6405.mail.yahoo.com; Wed, 11 Oct 2000 22:28:29 NZDT
Date: Wed, 11 Oct 2000 22:28:29 +1300 (NZDT)
From: =?iso-8859-1?q?Danny=20Smith?= <danny_r_smith_2001@yahoo.co.nz>
Subject: Re: AW: Linking Dynamic Libraries
To: cygwin@sources.redhat.com
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Status: RO
Content-Length: 1133
Lines: 38

Ross Smith wrote:
> 
> Charles Wilson wrote:
> >
> > You still need to worry about things like __declspec(dllexport) and
> > __declspec(dllimport).
> 
> What's the point of --export-all-symbols then? I was under the
> impression that it was intended to duplicate the Unix convention,
where
> all external symbols are automatically exported from a .so.
(Actually,
> the help refers to "global" symbols, not "external", but I assumed
that
> just meant that whoever wrote the help didn't know C++.)


If you really want to --export-all in C++, this is a workaround.
Create a def with dlltool:
 dlltool --export-all --output-def foo_.def --dllname foo.dll *.o

Then look at the def file.  Do you still really want to export-all?

To use that def file with ld -shared you need to get rid of the
comments (demangled names) 
cut does the job:
  cut -d ';' -f 1 foo_.def >foo.def

Cheers


_____________________________________________________________________________
http://clubs.yahoo.com.au - Yahoo! Clubs
- Join a club or build your own!

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com