t__alloc_die,DATA
>> ...
>>-link -EXPORT:lt_ltdl_LTX_preloaded_symbols,DATA
>> ...
>>
>> So, there are indeed data exports in libltdl. Anyone trying to make use of
>> those exports w/o LT_SCOPE doing the dllimport dance will probably fail. So,
>> we need a
; So, there are indeed data exports in libltdl. Anyone trying to make use of
> those exports w/o LT_SCOPE doing the dllimport dance will probably fail. So,
> we need a test case exercising one or the other of those exports. Or both.
I tried briefly to write tests for those two and quickly ran
On 10/25/2011 11:51 AM, Gary V. Vaughan wrote:
I have to bow to your superior knowledge of Windows, which I haven't used
for development since Windows NT 4, but it feels weird that Libltdl really
does twist itself into a pretzel for Windows... and yet all the other GNU
projects I've looked at do
Hi Gary,
Gary V. Vaughan wrote:
Hi Chuck,
I note that no other GNU projects that I'm aware of jump through all the
__declspec hoops that the libltdl API tries to provide through LT_SCOPE.
Is any of this stuff still required on any non-museum Windows compiler
that would break if I remov
re importantly, I also found this in the build logs of both
stock 2.4.2 and 2.4.2-no-lt-scope:
cl -link -EXPORT:lt__alloc_die,DATA
...
-link -EXPORT:lt_ltdl_LTX_preloaded_symbols,DATA
...
So, there are indeed data exports in libltdl. Anyone trying to make use of
those exports w/o LT_S
e of jump through all the
>>>> __declspec hoops that the libltdl API tries to provide through LT_SCOPE.
>>>> Is any of this stuff still required on any non-museum Windows compiler
>>>> that would break if I removed it?
>>>
>>> Isn't this funct
tdl API tries to provide through LT_SCOPE.
>>> Is any of this stuff still required on any non-museum Windows compiler
>>> that would break if I removed it?
>>
>> Isn't this functionality required for every Windows compiler other than GCC?
That certainly used to
other GNU projects that I'm aware of jump through all the
>>> __declspec hoops that the libltdl API tries to provide through LT_SCOPE.
>>> Is any of this stuff still required on any non-museum Windows compiler
>>> that would break if I removed it?
>>
>>
On 10/25/2011 11:03 AM, Peter Rosin wrote:
> Gary V. Vaughan skrev 2011-10-25 14:17:
> I configures both the way I usually configure libtool for msvc, i.e.
>
> ../configure autobuild_mode=msvc CC="/c/cygwin/home/peda/automake/lib/compile
> cl" CFLAGS="-MD -Zi -EHsc" CXX="/c/cygwin/home/peda/autom
Gary V. Vaughan skrev 2011-10-25 14:17:
> Hi Peter,
>
> On 25 Oct 2011, at 18:12, Peter Rosin wrote:
>> Gary V. Vaughan skrev 2011-10-25 12:51:
>>> I note that no other GNU projects that I'm aware of jump through all the
>>> __declspec hoops that the libltdl
Bob Friesenhahn skrev 2011-10-25 16:00:
> On Tue, 25 Oct 2011, Gary V. Vaughan wrote:
>
>> Hi Chuck,
>>
>> I note that no other GNU projects that I'm aware of jump through all the
>> __declspec hoops that the libltdl API tries to provide through LT_SCOPE.
>&g
On 10/25/2011 6:51 AM, Gary V. Vaughan wrote:
> Do you forsee any issues on Windows with my doing that?
Yes.
> I'm almost certain that modern gcc and hence cygwin and variants will
> continue to work correctly without LT_SCOPE, LTDL_DLL_IMPORT and friends,
> but I have no cl
On Tue, 25 Oct 2011, Gary V. Vaughan wrote:
Hi Chuck,
I note that no other GNU projects that I'm aware of jump through all the
__declspec hoops that the libltdl API tries to provide through LT_SCOPE.
Is any of this stuff still required on any non-museum Windows compiler
that would break
Hi Peter,
On 25 Oct 2011, at 18:12, Peter Rosin wrote:
> Gary V. Vaughan skrev 2011-10-25 12:51:
>> I note that no other GNU projects that I'm aware of jump through all the
>> __declspec hoops that the libltdl API tries to provide through LT_SCOPE.
>> Is any of this s
Gary V. Vaughan skrev 2011-10-25 12:51:
> Hi Chuck,
>
> I note that no other GNU projects that I'm aware of jump through all the
> __declspec hoops that the libltdl API tries to provide through LT_SCOPE.
> Is any of this stuff still required on any non-museum Windows compile
Hi Chuck,
I note that no other GNU projects that I'm aware of jump through all the
__declspec hoops that the libltdl API tries to provide through LT_SCOPE.
Is any of this stuff still required on any non-museum Windows compiler
that would break if I removed it?
Here's what I'm prop
On Mon, 30 Nov 2009, Gary V. Vaughan wrote:
Is it safe to remove all the ugly LT_SCOPE glue from libltdl yet
(without breaking correct compilation on any of the Windows based
systems we to support)?
Without this ugly LT_SCOPE glue it is not possible to support the
Microsoft C compiler as
Is it safe to remove all the ugly LT_SCOPE glue from libltdl yet (without
breaking correct compilation on any of the Windows based systems we to support)?
Cheers,
Gary
--
Gary V. Vaughan (g...@gnu.org)
___
http://lists.gnu.org/mailman/listinfo
If I have both DLL_EXPORT and LIBLTDL_DLL_IMPORT
defined when including , I get
In file included from foo.c:1:
/usr/local/mingw/include/ltdl.h:134: warning: `LT_SCOPE' redefined
/usr/local/mingw/include/ltdl.h:131: warning: this is the location of
the previous definition
This will stop eve
Hello list,
in the current libltdl package (1.4.2) you are marking the allocator
function pointers (malloc, realloc, free) with LT_SCOPE in order to
indicate the linker on M$-Windows to import/export it from the DLL. Why
don't you do this with all other code symbols?
Thanks in ad
20 matches
Mail list logo
