libtool

libtool

[Robert Collins]

I went and tried libtool after the post that libtool supported dll
creation...

I have a problem with the dll creation from libtool 1.3.4 and 1.3.5. I know
this isn't the libtool list.. but this is a cygwin specific issue..

I have applied the dll_entry patch for cygwin 1.1.4 (which I am running).

The error reported from make is:
---
 test -f .libs/libglib-1-2-0-0-8.dll-ltdll.o || (cd .libs && gcc -c
libglib-1-2-
0-0-8.dll-ltdll.c)
libglib-1-2-0-0-8.dll-ltdll.c:23: conflicting types for `DllMain'
libglib-1-2-0-0-8.dll-ltdll.c:16: previous declaration of `DllMain'
libglib-1-2-0-0-8.dll-ltdll.c:23: conflicting types for `_cygwin_dll_entry'
libglib-1-2-0-0-8.dll-ltdll.c:23: previous declaration of
`_cygwin_dll_entry'
libglib-1-2-0-0-8.dll-ltdll.c:30: conflicting types for `DllMain'
libglib-1-2-0-0-8.dll-ltdll.c:23: previous declaration of `DllMain'
---

libglib-1-2-0-0-8.dll-ltdll.c is as follows
---
/* ltdll.c starts here */
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#undef WIN32_LEAN_AND_MEAN
#include <stdio.h>
#
#ifndef __CYGWIN__
#  ifdef __CYGWIN32__
#    define __CYGWIN__ __CYGWIN32__
#  endif
#endif

#ifdef __cplusplus
extern "C" {
#endif
BOOL APIENTRY DllMain (HINSTANCE hInst, DWORD reason, LPVOID reserved);
#ifdef __cplusplus
}
#endif

#ifdef __CYGWIN__
#include <cygwin/cygwin_dll.h>
DECLARE_CYGWIN_DLL( DllMain );
#endif

HINSTANCE __hDllInstance_base;
#
BOOL APIENTRY
DllMain (HINSTANCE hInst, DWORD reason, LPVOID reserved)
{
  __hDllInstance_base = hInst;
  return TRUE;
}
/* ltdll.c ends here */
---

if I change the *ltdll.c file to
--
/* ltdll.c starts here */
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#undef WIN32_LEAN_AND_MEAN
#include <stdio.h>
#
#ifndef __CYGWIN__
#  ifdef __CYGWIN32__
#    define __CYGWIN__ __CYGWIN32__
#  endif
#endif
#ifndef __CYGWIN__
#ifdef __cplusplus
extern "C" {
#endif
BOOL APIENTRY DllMain (HINSTANCE hInst, DWORD reason, LPVOID reserved);
#ifdef __cplusplus
}
#endif
#else
#ifdef __CYGWIN__
#include <cygwin/cygwin_dll.h>
//DECLARE_CYGWIN_DLL( DllMain );
#endif
#endif
HINSTANCE __hDllInstance_base;
#
int  WINAPI
DllMain (HANDLE h, DWORD reason, void *ptr)
{
  __hDllInstance_base = h;
  return TRUE;
}
/* ltdll.c ends here */
--

it compiles the dll, .la, .lai files ok.
but.. I get a reports of syntax error in the def file, and application
compiled to use the library get undefined references to the functions in
it - which I thought libtool was meant to handle...


I'll happily go bug the libtool lists if that's appropriate..
Rob


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

Re: libtool

[Gary V. Vaughan]

Hi Rob,

On Wed, Sep 06, 2000 at 12:47:00AM +1100, Robert Collins wrote:
> I went and tried libtool after the post that libtool supported dll
> creation...
> 
> I have a problem with the dll creation from libtool 1.3.4 and 1.3.5. I know
> this isn't the libtool list.. but this is a cygwin specific issue..

Hmm.  You're right.  How embarrassing!  The same problem afflicts CVS
HEAD revision of libtool too.

What has changed in the build procedure for cygwin dlls between b20.1
(where I had tested all the changes I made to libtool for dll
generation) and cygwin-1.1.2 (where it no longer works) =(O|

> I'll happily go bug the libtool lists if that's appropriate..

If you know what needs to be done to fix it (I'm afraid that I don't)
please do post to the libtool list and I will make sure that the
necessary changes get into the tree before I release libtool-1.4.

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

Re: libtool

[Earnie Boyd]

--- Robert Collins <robert.collins@itdomain.com.au> wrote:
> ----- Original Message -----
> From: "Chris Faylor" <cgf@cygnus.com>
> To: <cygwin@sources.redhat.com>
> Sent: Friday, September 08, 2000 8:14 AM
> Subject: Re: libtool
> 
> 
> > On Fri, Sep 08, 2000 at 08:02:46AM +1100, Robert Collins wrote:
> > >I played around last night... pity I don't know dlls that well :-]
> > >
> > >1) the ltdll.c header seems unneeded with current gcc
> >
> >gcc -shared -g -O2 -Wall,--enable-auto-image-base,--out-imp-lib=.libs/libna
> m
> > >e.dll.a -o .libs/libname.dll -export-dynamic a.lo b.lo c.lo
> > >
> > >built a dll quite happily from standard sources except there were no
> > >exports...
> > >I presume that's what the sed and DLLTOOL scripts in the current libtool
> are
> > >all about? generating a .def file to explicitly list the exports?
> > >
> > >2) the .def files format was broken
> > >-> I haven't looked at this yet
> > >
> > >3) the .def file had many un-related symbols pulled via dlltool and sed.
> > >(i.e. printf as an export from glib...)
> > >I'm kicking around using NM and searching for T entries in the .lo files
> > >rather than libtool --export-all
> > >
> > >comments anyone?
> >
> > What about 'D' entries?
> 
> Thank you.. I've realised I probably asking the wrong question...
> 
> is there an existing tool that will pull the following symbols from a
> collection of .lo files:
> * explicitly _declspec(dllexport) symbols
> * any symbols that could be linked to the .lo files if they were collected
> into a static library. (phrased badly I know)
> currently libtool uses dlltool --export-all -z mydeffile.def a.lo b.lo ...
> d.lo where the .lo files are what will be linked to created the .dll
> 
> the symbols are used to created import and export .def files so that the .h
> files do not need to explicitly use declspec(dllimport) etc.
> 
> if there is no existing tool... can anyone recommend documentation that
> might help me specify what said tool needs to do to get only those symbols?
> there are T (haven't looked at D yet) symbols that are part of core system
> libraries (to pick two of them T _malloc or T _strcmp). I don't think glib
> (my test libtooled library overrides those function itself).
> 

Anders Norlander had created a pexports process that would create the .def from
the supplied headers and the .dll.  Is there a link to this at http://sources.redhat.com/cygwin/ ?

=====
--- < http://earniesystems.safeshopper.com > ---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://gw32.freeyellow.com/ >
           __Minimalist GNU for Windows__
  Mingw32 List: < http://www.egroups.com/group/mingw32/ >
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

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

Re: libtool

[Gary V. Vaughan]

On Sun, Sep 10, 2000 at 01:23:14PM -0400, Charles S. Wilson wrote:
> I don't believe the following behavior is possible in the current
> libtool. However, if it is, please correct me.

Nope.  How can libtool know what types of library an object will
eventually be linked with.

   libtool --mode=compile gcc -c foo.c -o foo.lo

Perhaps we could teach automake to analyse the make rules and pass
more details to libtool on the link line?  It would be quite a big
job, and I am no Perl hacker =(O|  We would need something like:

   libtool --mode=compile gcc -c foo.c -o foo.lo --links-with=libbar.la
   
Hmmm.  Even that is not enough.  automake would also need to analyse
the link command to determine whether the user has specified -static
to force static linking -- and probably a buch of other complications
I didn't consider.

> In the upcoming libtool (1.4?) it would be nice on cygwin/windows-ish
> platforms, if the libfoo.la file could instruct libtool that it may need
> different -Ddefines when compiling an object file that is to be linked
> to a static lib or to a dynamic lib (dll).

Have you seen the recipe I am using for m4-1.5?  Or in my snprintfv
library? (both available from my home page).  <shameless plug>I have
also written a chapter about using GNU autotools on Cygwin for the
forthcoming book `Autoconf, Automake and Libtool' from NewRiders,
which describes the systewm I use in some detail.</shameless plug>.

> For instance, on cygwin, if compiling/linking my-file.c and I want to
> link to libz statically, I need the following (when compiling/linking by
> hand, no libtool):
> 
> gcc -c -DZLIB_STATIC -o my-file.o myfile.c
> gcc -static -o my-file.exe my-file.o -L<path> -lz
> 
> If I want to link dynamically, I need:
> 
> gcc -c -o my-file.o myfile.c
> gcc -o my-file.exe my-file.o -L<path> -lz
> 
> That is, both the compile and the link steps are different.  Is it
> possible for this information to be embedded in libfoo.la (libz.la in
> this case) -- so that libtool knows that 'statically linked packages
> that depend on libz must have -DZLIB_STATIC in the compile step', while
> 'dynamically linked packages that depend on libz need no special
> -Ddefines in the compile step'.
> 
> Similarly, you need -DPNG_STATIC for libpng, -DJPEG_STATIC for libjpeg,
> etc...

At the object level, often it is only the developer who really knows
exactly which combination of libraries a module will eventually link
with.  And even they may not be sure which combination is present on
one of their user's machines at install time.  You are correct in that
this would be a nice feature -- but it is only necessary for Win32
systems, and is *a lot* of work, so don't hold your breath.

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

Re: libtool

[Charles S. Wilson]

I don't believe the following behavior is possible in the current
libtool. However, if it is, please correct me.

In the upcoming libtool (1.4?) it would be nice on cygwin/windows-ish
platforms, if the libfoo.la file could instruct libtool that it may need
different -Ddefines when compiling an object file that is to be linked
to a static lib or to a dynamic lib (dll).

For instance, on cygwin, if compiling/linking my-file.c and I want to
link to libz statically, I need the following (when compiling/linking by
hand, no libtool):

gcc -c -DZLIB_STATIC -o my-file.o myfile.c
gcc -static -o my-file.exe my-file.o -L<path> -lz

If I want to link dynamically, I need:

gcc -c -o my-file.o myfile.c
gcc -o my-file.exe my-file.o -L<path> -lz

That is, both the compile and the link steps are different.  Is it
possible for this information to be embedded in libfoo.la (libz.la in
this case) -- so that libtool knows that 'statically linked packages
that depend on libz must have -DZLIB_STATIC in the compile step', while
'dynamically linked packages that depend on libz need no special
-Ddefines in the compile step'.

Similarly, you need -DPNG_STATIC for libpng, -DJPEG_STATIC for libjpeg,
etc...

--Chuck

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

Re: libtool

[Robert Collins]

You might find this amusing

libtool 1.3.5 from ftp.gnu.org when configuring
...
checking dynamic linker characteristics... Win32 ld.exe
checking if libtool supports shared libraries... yes
checking if package supports dlls... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes

so it won't dllise itself :-]

Rob

----- Original Message -----
From: "Gary V. Vaughan" <gvv@techie.com>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <cygwin@sources.redhat.com>
Sent: Saturday, September 09, 2000 11:41 PM
Subject: Re: libtool


> On Sat, Sep 09, 2000 at 09:42:38PM +1100, Robert Collins wrote:
> >     Other than hanging on make check your tar.gz built fine for me...
>
> You need to force it to use the supplied getopts files -- the system
> ones seem to be buggy.  Try this:
>
>   ac_cv_func_getopt_long=no ./configure --with-modules --disable-nls
>
>
> > how can I take the libtool you have in that archive and apply it to
> > (say glib or orbit)?
>
> You can extract the parts of libtool.m4 and ltdl.m4 from aclocal.m4
> and add them to acinclude.m4 in your glib $top_srcdir.  This stuff is
> between the definitions of AC_PROG_LIBTOOL and the end of
> AC_LTDL_SYMBOL_USCORE.  You should then copy the ltconfig and
> ltmain.sh from m4-1.4p over the versions you have in glib.
>
> aclocal
> automake
> autoconf
>
> and be careful not to clobber your hard work by running libtoolize!
>
> > I realise exported variables need to be wrapped with declspec(dllexport)
> > before building the dll but I thought you had the functions being done
> > automatically? Is that an incorrect assumption?
>
> You assumption is correct.  Gcc takes care of non-data exports.
>
> HTH,
> 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
>
>


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

Re: libtool

[Gary V. Vaughan]

On Sat, Sep 09, 2000 at 09:42:38PM +1100, Robert Collins wrote:
>     Other than hanging on make check your tar.gz built fine for me...

You need to force it to use the supplied getopts files -- the system
ones seem to be buggy.  Try this:

  ac_cv_func_getopt_long=no ./configure --with-modules --disable-nls
  

> how can I take the libtool you have in that archive and apply it to
> (say glib or orbit)?

You can extract the parts of libtool.m4 and ltdl.m4 from aclocal.m4
and add them to acinclude.m4 in your glib $top_srcdir.  This stuff is
between the definitions of AC_PROG_LIBTOOL and the end of
AC_LTDL_SYMBOL_USCORE.  You should then copy the ltconfig and
ltmain.sh from m4-1.4p over the versions you have in glib.

aclocal
automake
autoconf

and be careful not to clobber your hard work by running libtoolize!

> I realise exported variables need to be wrapped with declspec(dllexport)
> before building the dll but I thought you had the functions being done
> automatically? Is that an incorrect assumption?

You assumption is correct.  Gcc takes care of non-data exports.

HTH,
	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

Re: libtool

[Robert Collins]

Gary,
    Other than hanging on make check your tar.gz built fine for me... how
can I take the libtool you have in that archive and apply it to (say glib or
orbit)?
I realise exported variables need to be wrapped with declspec(dllexport)
before building the dll but I thought you had the functions being done
automatically? Is that an incorrect assumption?

Thanks,
Rob


----- Original Message -----
From: "Gary V. Vaughan" <gvv@techie.com>
To: "Earnie Boyd" <earnie_boyd@yahoo.com>
Cc: "Robert Collins" <robert.collins@itdomain.com.au>;
<cygwin@sources.redhat.com>
Sent: Friday, September 08, 2000 11:27 AM
Subject: Re: libtool


> On Thu, Sep 07, 2000 at 06:55:50PM +0100, Gary V. Vaughan wrote:
> >
> > I'll upgrade to cygwin 1.1.4 and post some traces later tonight in the
> > hope that someone can make more sense of them than I can.
>
> I updated to the very latest cygwin stuff using the web setup.exe, and
> tried to compile a program that I know definitely built on my b20.1
> installation a few weeks back (a prerelease of GNU m4 1.5, available
> from my website).  It uses link time and runtime (LoadLibrary()) dll's
> and is a pretty good stress test for libtool's dll support.
>
> To my surprise, it worked!  Here is a part of the log around where the
> build is compiling the libm4.la dll:
>
> .
> .
> .
> /bin/sh ../libtool --mode=link gcc  -g -O2 -no-undefined -export-dynamic
@DLLDFLAGS@ -o libm4.la -rpath /usr/local/lib  list.lo m4module.lo error.lo
obstack.lo regex.lo xmalloc.lo xstrdup.lo
> rm -fr .libs/libm4.la .libs/libm4.* .libs/libm4.*
> generating symbol list for `libm4.la'
> dlltool --export-all --exclude-symbols
DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12,DllMainCRTSta
rtup@12,DllEntryPoint@12 --output-def .libs/libm4-0-0-0.dll-def  list.lo
m4module.lo error.lo obstack.lo regex.lo xmalloc.lo xstrdup.lo
> sed -e "1,/EXPORTS/d" -e "s/ @ [0-9]*//" -e "s/ *;.*$//" <
.libs/libm4-0-0-0.dll-def > .libs/libm4.exp
> echo EXPORTS > .libs/libm4-0-0-0.dll-def
> _lt_hint=1; \
> cat .libs/libm4.exp | while read symbol; do \
>   set dummy $symbol; \
>   case $# in \
>     2) echo " $2 @ $_lt_hint ; " >> .libs/libm4-0-0-0.dll-def ;; \
>     *) echo " $2 @ $_lt_hint $3 ; " >> .libs/libm4-0-0-0.dll-def ;; \
>   esac; \
>   _lt_hint=`expr 1 + $_lt_hint`; \
> done
>
gcc -Wl,--base-file,.libs/libm4-0-0-0.dll-base -Wl,--dll -nostartfiles -Wl,-
e,__cygwin_dll_entry@12 -o .libs/libm4-0-0-0.dll list.lo m4module.lo
error.lo obstack.lo regex.lo xmalloc.lo xstrdup.lo
> dlltool --as=as --dllname libm4-0-0-0.dll --exclude-symbols
DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12,DllMainCRTSta
rtup@12,DllEntryPoint@12--def .libs/libm4-0-0-0.dll-def --base-file
.libs/libm4-0-0-0.dll-base--output-exp .libs/libm4-0-0-0.dll-exp
> gcc -Wl,--base-file,.libs/libm4-0-0-0.dll-base
.libs/libm4-0-0-0.dll-exp -Wl,--dll -nostartfiles -Wl,-e,__cygwin_dll_entry@
12 -o .libs/libm4-0-0-0.dll  list.lo m4module.lo error.lo obstack.lo
regex.lo xmalloc.lo xstrdup.lo
> dlltool --as=as --dllname libm4-0-0-0.dll --exclude-symbols
DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12,DllMainCRTSta
rtup@12,DllEntryPoint@12  --def .libs/libm4-0-0-0.dll-def --base-file
.libs/libm4-0-0-0.dll-base --output-exp .libs/libm4-0-0-0.dll-exp
> gcc
.libs/libm4-0-0-0.dll-exp -Wl,--dll -nostartfiles -Wl,-e,__cygwin_dll_entry@
12 -o .libs/libm4-0-0-0.dll  list.lo m4module.lo error.lo obstack.lo
regex.lo xmalloc.lo xstrdup.lo
> creating libm4.la
> .
> .
> .
>
> Cheers,
> Gary.
>
> p.s.  I think the current cvs HEAD of libtool is broken wrt cygwin
>       right now.
>
> p.p.s.  the version of getopts linked by the system is subtly broken
>         and causes this m4 build to fail most of it's tests due to
> misparsing of the command line.  Linking it with the getopt
> files in the distribution works fine, and the build passes all
> tests.
> --
>   ___              _   ___   __              _         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

Re: libtool

[Charles S. Wilson]

Robert Collins wrote:

> gcc -shared -g -O2 -Wall,--enable-auto-image-base,--out-imp-lib=.libs/libnam
> e.dll.a -o .libs/libname.dll -export-dynamic a.lo b.lo c.lo

I think this should be:

gcc -shared -g -O2 -Wall -Wl,--enable-auto-image-base
-Wl,--out-implib=.lib/libname.dll.a -Wl,--export-all-symbols -o
./libs/libname.dll a.lo b.lo c.lo

That is, '-Wl,--out-implib=' not '-Wl,--out-imp-lib'
'-Wl,--export-all-symbols' not '-export-dynamic'

This second one is why you had no exports -- the linker never saw the
'--export-dynamic' command because gcc ate and ignored it (plus, even if
the linker saw '--export-dynamic' it would ignore it, too, because it's
the wrong command).

> 
> built a dll quite happily from standard sources except there were no
> exports...


> 
> 2) the .def files format was broken
> -> I haven't looked at this yet

If you want ld to write the <in-memory, auto-generated> def-file to
disk, then you need '-Wl,--output-def=.libs/libname.def'

--Chuck

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

Re: libtool

[Gary V. Vaughan]

On Thu, Sep 07, 2000 at 06:55:50PM +0100, Gary V. Vaughan wrote:
> 
> I'll upgrade to cygwin 1.1.4 and post some traces later tonight in the
> hope that someone can make more sense of them than I can.

I updated to the very latest cygwin stuff using the web setup.exe, and
tried to compile a program that I know definitely built on my b20.1
installation a few weeks back (a prerelease of GNU m4 1.5, available
from my website).  It uses link time and runtime (LoadLibrary()) dll's
and is a pretty good stress test for libtool's dll support.

To my surprise, it worked!  Here is a part of the log around where the
build is compiling the libm4.la dll:

.
.
.
/bin/sh ../libtool --mode=link gcc  -g -O2 -no-undefined -export-dynamic @DLLDFLAGS@ -o libm4.la -rpath /usr/local/lib  list.lo m4module.lo error.lo obstack.lo regex.lo xmalloc.lo xstrdup.lo
rm -fr .libs/libm4.la .libs/libm4.* .libs/libm4.*
generating symbol list for `libm4.la'
dlltool --export-all --exclude-symbols DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12,DllMainCRTStartup@12,DllEntryPoint@12 --output-def .libs/libm4-0-0-0.dll-def  list.lo m4module.lo error.lo obstack.lo regex.lo xmalloc.lo xstrdup.lo 
sed -e "1,/EXPORTS/d" -e "s/ @ [0-9]*//" -e "s/ *;.*$//" < .libs/libm4-0-0-0.dll-def > .libs/libm4.exp
echo EXPORTS > .libs/libm4-0-0-0.dll-def
_lt_hint=1; \
cat .libs/libm4.exp | while read symbol; do \
  set dummy $symbol; \
  case $# in \
    2) echo " $2 @ $_lt_hint ; " >> .libs/libm4-0-0-0.dll-def ;; \
    *) echo " $2 @ $_lt_hint $3 ; " >> .libs/libm4-0-0-0.dll-def ;; \
  esac; \
  _lt_hint=`expr 1 + $_lt_hint`; \
done
gcc -Wl,--base-file,.libs/libm4-0-0-0.dll-base -Wl,--dll -nostartfiles -Wl,-e,__cygwin_dll_entry@12 -o .libs/libm4-0-0-0.dll list.lo m4module.lo error.lo obstack.lo regex.lo xmalloc.lo xstrdup.lo  
dlltool --as=as --dllname libm4-0-0-0.dll --exclude-symbols DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12,DllMainCRTStartup@12,DllEntryPoint@12--def .libs/libm4-0-0-0.dll-def --base-file .libs/libm4-0-0-0.dll-base--output-exp .libs/libm4-0-0-0.dll-exp
gcc -Wl,--base-file,.libs/libm4-0-0-0.dll-base .libs/libm4-0-0-0.dll-exp -Wl,--dll -nostartfiles -Wl,-e,__cygwin_dll_entry@12 -o .libs/libm4-0-0-0.dll  list.lo m4module.lo error.lo obstack.lo regex.lo xmalloc.lo xstrdup.lo  
dlltool --as=as --dllname libm4-0-0-0.dll --exclude-symbols DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12,DllMainCRTStartup@12,DllEntryPoint@12  --def .libs/libm4-0-0-0.dll-def --base-file .libs/libm4-0-0-0.dll-base --output-exp .libs/libm4-0-0-0.dll-exp
gcc .libs/libm4-0-0-0.dll-exp -Wl,--dll -nostartfiles -Wl,-e,__cygwin_dll_entry@12 -o .libs/libm4-0-0-0.dll  list.lo m4module.lo error.lo obstack.lo regex.lo xmalloc.lo xstrdup.lo
creating libm4.la
.
.
.

Cheers,
	Gary.
	
p.s.  I think the current cvs HEAD of libtool is broken wrt cygwin
      right now.
      
p.p.s.  the version of getopts linked by the system is subtly broken
        and causes this m4 build to fail most of it's tests due to
	misparsing of the command line.  Linking it with the getopt
	files in the distribution works fine, and the build passes all
	tests. 
-- 
  ___              _   ___   __              _         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

Re: libtool

[Robert Collins]

----- Original Message -----
From: "Chris Faylor" <cgf@cygnus.com>
To: <cygwin@sources.redhat.com>
Sent: Friday, September 08, 2000 8:14 AM
Subject: Re: libtool


> On Fri, Sep 08, 2000 at 08:02:46AM +1100, Robert Collins wrote:
> >I played around last night... pity I don't know dlls that well :-]
> >
> >1) the ltdll.c header seems unneeded with current gcc
>
>gcc -shared -g -O2 -Wall,--enable-auto-image-base,--out-imp-lib=.libs/libna
m
> >e.dll.a -o .libs/libname.dll -export-dynamic a.lo b.lo c.lo
> >
> >built a dll quite happily from standard sources except there were no
> >exports...
> >I presume that's what the sed and DLLTOOL scripts in the current libtool
are
> >all about? generating a .def file to explicitly list the exports?
> >
> >2) the .def files format was broken
> >-> I haven't looked at this yet
> >
> >3) the .def file had many un-related symbols pulled via dlltool and sed.
> >(i.e. printf as an export from glib...)
> >I'm kicking around using NM and searching for T entries in the .lo files
> >rather than libtool --export-all
> >
> >comments anyone?
>
> What about 'D' entries?

Thank you.. I've realised I probably asking the wrong question...

is there an existing tool that will pull the following symbols from a
collection of .lo files:
* explicitly _declspec(dllexport) symbols
* any symbols that could be linked to the .lo files if they were collected
into a static library. (phrased badly I know)
currently libtool uses dlltool --export-all -z mydeffile.def a.lo b.lo ...
d.lo where the .lo files are what will be linked to created the .dll

the symbols are used to created import and export .def files so that the .h
files do not need to explicitly use declspec(dllimport) etc.

if there is no existing tool... can anyone recommend documentation that
might help me specify what said tool needs to do to get only those symbols?
there are T (haven't looked at D yet) symbols that are part of core system
libraries (to pick two of them T _malloc or T _strcmp). I don't think glib
(my test libtooled library overrides those function itself).

Rob



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

Re: libtool

[Chris Faylor]

On Fri, Sep 08, 2000 at 08:02:46AM +1100, Robert Collins wrote:
>I played around last night... pity I don't know dlls that well :-]
>
>1) the ltdll.c header seems unneeded with current gcc
>gcc -shared -g -O2 -Wall,--enable-auto-image-base,--out-imp-lib=.libs/libnam
>e.dll.a -o .libs/libname.dll -export-dynamic a.lo b.lo c.lo
>
>built a dll quite happily from standard sources except there were no
>exports...
>I presume that's what the sed and DLLTOOL scripts in the current libtool are
>all about? generating a .def file to explicitly list the exports?
>
>2) the .def files format was broken
>-> I haven't looked at this yet
>
>3) the .def file had many un-related symbols pulled via dlltool and sed.
>(i.e. printf as an export from glib...)
>I'm kicking around using NM and searching for T entries in the .lo files
>rather than libtool --export-all
>
>comments anyone?

What about 'D' entries?

cgf

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

Re: libtool

[Robert Collins]

I played around last night... pity I don't know dlls that well :-]

1) the ltdll.c header seems unneeded with current gcc
gcc -shared -g -O2 -Wall,--enable-auto-image-base,--out-imp-lib=.libs/libnam
e.dll.a -o .libs/libname.dll -export-dynamic a.lo b.lo c.lo

built a dll quite happily from standard sources except there were no
exports...
I presume that's what the sed and DLLTOOL scripts in the current libtool are
all about? generating a .def file to explicitly list the exports?

2) the .def files format was broken
-> I haven't looked at this yet

3) the .def file had many un-related symbols pulled via dlltool and sed.
(i.e. printf as an export from glib...)
I'm kicking around using NM and searching for T entries in the .lo files
rather than libtool --export-all

comments anyone?

Rob


----- Original Message -----
From: "Gary V. Vaughan" <gvv@techie.com>
To: "Earnie Boyd" <earnie_boyd@yahoo.com>
Cc: "Robert Collins" <robert.collins@itdomain.com.au>;
<cygwin@sources.redhat.com>
Sent: Friday, September 08, 2000 4:55 AM
Subject: Re: libtool


> On Thu, Sep 07, 2000 at 06:34:30AM -0700, Earnie Boyd wrote:
> > --- "Gary V. Vaughan" <gvv@techie.com> wrote:
> > >
> > > What has changed in the build procedure for cygwin dlls between b20.1
> > > (where I had tested all the changes I made to libtool for dll
> > > generation) and cygwin-1.1.2 (where it no longer works) =(O|
> > >
> >
> > One of the things that changed that might affect this is the handling of
paths
> > with a \ in the string.  So, that \usr is not the same as /usr.  Could
this be
> > the problem?  I don't know I have tried libtool recently.
>
> I don't think so.  Internally, libtool always uses '/' delimitters.
> It *should* propogate '\' correctly on cygwin if such a path is passed
> in by automake or somesuch -- however, if not, it has always been
> broken, and isn't a new problem.
>
> I'll upgrade to cygwin 1.1.4 and post some traces later tonight in the
> hope that someone can make more sense of them than I can.
>
> 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

Re: libtool

[Gary V. Vaughan]

On Thu, Sep 07, 2000 at 06:34:30AM -0700, Earnie Boyd wrote:
> --- "Gary V. Vaughan" <gvv@techie.com> wrote:
> > 
> > What has changed in the build procedure for cygwin dlls between b20.1
> > (where I had tested all the changes I made to libtool for dll
> > generation) and cygwin-1.1.2 (where it no longer works) =(O|
> > 
> 
> One of the things that changed that might affect this is the handling of paths
> with a \ in the string.  So, that \usr is not the same as /usr.  Could this be
> the problem?  I don't know I have tried libtool recently.

I don't think so.  Internally, libtool always uses '/' delimitters.
It *should* propogate '\' correctly on cygwin if such a path is passed
in by automake or somesuch -- however, if not, it has always been
broken, and isn't a new problem.

I'll upgrade to cygwin 1.1.4 and post some traces later tonight in the
hope that someone can make more sense of them than I can.

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

Re: libtool

[Earnie Boyd]

--- "Gary V. Vaughan" <gvv@techie.com> wrote:
> 
> What has changed in the build procedure for cygwin dlls between b20.1
> (where I had tested all the changes I made to libtool for dll
> generation) and cygwin-1.1.2 (where it no longer works) =(O|
> 

One of the things that changed that might affect this is the handling of paths
with a \ in the string.  So, that \usr is not the same as /usr.  Could this be
the problem?  I don't know I have tried libtool recently.

Cheers,

=====
--- < http://earniesystems.safeshopper.com > ---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://gw32.freeyellow.com/ >
           __Minimalist GNU for Windows__
  Mingw32 List: < http://www.egroups.com/group/mingw32/ >
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

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