>
> IMO, libtool should simply try and build the dll. If dll's need to be
> disabled, let the author do that via configure.in.
What means is provided to absolutely disable building DLLs (without
disabling building shared libraries in general) via configure.in?
Bob
On Sun, 2002-10-27 at 06:00, Bob Friesenhahn wrote:
> This is good info, however, the more pressing matter is that I don't
> see any evidence that AC_LIBTOOL_WIN32_DLL currently supports a
> flag which determines if DLLs will built.
>
> There is the variable lt_cv_cc_dll_switch but this is not use
This is good info, however, the more pressing matter is that I don't
see any evidence that AC_LIBTOOL_WIN32_DLL currently supports a
flag which determines if DLLs will built.
There is the variable lt_cv_cc_dll_switch but this is not used at all
by Cygwin anymore, and MinGW only uses it as a means
Oops. Looks like the uuencoded version of egor's stuff got scrambled.
I've MIME-atteched them here.
--Chuck
egor-patches-example.tar.bz2
Description: Binary data
long_long_example.tar.bz2
Description: Binary data
Earnie Boyd wrote:
Is it still true that global variables exported from a dll must have a
dllimport directive for applications? AC_LIBTOOL_WIN32_DLL would
perhaps indicate a package has addressed this issue (by whatever
means) and is therefore dll safe.
While this is required by MSVC, to my k
Robert Collins wrote:
On Sat, 2002-10-26 at 08:24, Bob Friesenhahn wrote:
On Sat, 26 Oct 2002, Kevin Ryde wrote:
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Comments?
Is it still true that global variables exported from a dll must have a
dllimport directive for applications? AC_LIBTOOL_W
On Sat, 2002-10-26 at 08:24, Bob Friesenhahn wrote:
> On Sat, 26 Oct 2002, Kevin Ryde wrote:
>
> > Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> > >
> > > Comments?
> >
> > Is it still true that global variables exported from a dll must have a
> > dllimport directive for applications? AC_LIBTOOL_
On Sat, 26 Oct 2002, Kevin Ryde wrote:
> Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> >
> > Comments?
>
> Is it still true that global variables exported from a dll must have a
> dllimport directive for applications? AC_LIBTOOL_WIN32_DLL would
> perhaps indicate a package has addressed this issu
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> Comments?
Is it still true that global variables exported from a dll must have a
dllimport directive for applications? AC_LIBTOOL_WIN32_DLL would
perhaps indicate a package has addressed this issue (by whatever
means) and is therefore dll safe.
__
Charles Wilson wrote:
The one remaining niggle is this: you *must* specify -no-undefined, or
libtool won't even attempt to build a DLL.
I agree.
But anyway, -no-undefined is a whole separate issue. As far as
AC_LIBTOOL_WIN32_DLL, from the cygwin perspective it can be killed.
However, give
When the AC_LIBTOOL_WIN32_DLL macro was originated, it was necessary
to add dllexport decorations to library source code in order to build
a DLL. When AC_LIBTOOL_WIN32_DLL was added to configure.in, it
enabled a few Windows specific tests, but most importantly, it enabled
building libraries as DLL
When the AC_LIBTOOL_WIN32_DLL macro was originated, it was necessary
to add dllexport decorations to library source code in order to build
a DLL. When AC_LIBTOOL_WIN32_DLL was added to configure.in, it
enabled a few Windows specific tests, but most importantly, it enabled
building libraries as DLL
12 matches
Mail list logo
