[/begin beat dead horse]
Howard Chu wrote:
Sorry, I was looking at 1.4.3, which is nowhere near as sophisticated as
that. Still the point remains, there's a fair chunk of processing here
to determine some things that the linker now handles transparently.
^^^
* Bob Friesenhahn wrote on Thu, Apr 28, 2005 at 04:34:53PM CEST:
> On Thu, 28 Apr 2005, Ralf Wildenhues wrote:
> >
> >BTW: Does anyone have access to non-gcc compilers on win32 and some
> >incentive to test Libtool HEAD with them?
> My understanding is that both the Microsoft and Borland command-l
On Thu, 28 Apr 2005, Ralf Wildenhues wrote:
BTW: Does anyone have access to non-gcc compilers on win32 and some
incentive to test Libtool HEAD with them? We need more test coverage
there (and probably a couple of patches, too).
My understanding is that both the Microsoft and Borland command-line
Hi Bob, Howard, others,
* Bob Friesenhahn wrote on Wed, Apr 27, 2005 at 06:34:47PM CEST:
> On Wed, 27 Apr 2005, Howard Chu wrote:
> >>
> >>Related question: Do I have to specify the declspec(export) in the same
> >>translation unit in which I define the function? This is what bugs us
> >>in mingw
Charles Wilson wrote:
Howard Chu wrote:
One other annoying gotcha when building with libtool and Win32 is that
libtool (at least in the 1.x line) assumed that any lib*.a was a
static library, and refused to link it into a DLL. It didn't account
for the possibility that the library was actually a
Howard Chu wrote:
One other annoying gotcha when building with libtool and Win32 is that
libtool (at least in the 1.x line) assumed that any lib*.a was a static
library, and refused to link it into a DLL. It didn't account for the
possibility that the library was actually a DLL import library. N
Bob Friesenhahn wrote:
I see that more recent versions of cygwin/mingw appear to have made
using declspec unnecessary:
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html
I don't know how others would feel about it, but perhaps you could
just say "version >= XX of
Ralf Wildenhues wrote:
In branch-2-0 and HEAD we actually don't use the lt_*alloc/free
interface any more, seems for good reason. We do still define a stub
interface for backward compatibility, but given these arguments, I think
we can safely delete them completely, or at least hide them on win32.
On Wed, 27 Apr 2005, Howard Chu wrote:
Related question: Do I have to specify the declspec(export) in the same
translation unit in which I define the function? This is what bugs us
in mingw ATM. Specifying the declspec in another translation unit
seems to work with cygwin but fail on mingw. (Of
Hi Howard,
* Howard Chu wrote on Wed, Apr 27, 2005 at 04:18:12PM CEST:
> Ralf Wildenhues wrote:
>
> >>Since LT_SCOPE is only used for the three lt_*alloc/free function
> >>pointers, I suggest removing these declarations completely and using
> >>accessor functions to set/get their values.
>
> >
Ralf Wildenhues wrote:
This situation is quite ugly because it means the user's *code* has to
know whether they are linking against a shared or static libltdl, and
it's just not possible to determine this dynamically/automatically at
compile time.
Hehe. Note that I have only very limited knowl
Hi Howard,
* Howard Chu wrote on Tue, Apr 26, 2005 at 02:40:45PM CEST:
> The definition of LT_SCOPE in libltdl/ltdl.h needs a tweak; if some
> other DLL (e.g. module 'foo') uses libltdl then it needs to define
> LIBLTDL_DLL_IMPORT. Since 'foo' is compiled as a DLL, DLL_EXPORT will
> already be
The definition of LT_SCOPE in libltdl/ltdl.h needs a tweak; if some
other DLL (e.g. module 'foo') uses libltdl then it needs to define
LIBLTDL_DLL_IMPORT. Since 'foo' is compiled as a DLL, DLL_EXPORT will
already be automatically defined, resulting in LT_SCOPE getting defined
twice. A quick sol
13 matches
Mail list logo
