gnuplot-beta

using bgd.dll on windows

[Bastian M. <bma...@we...>]

While trying to compile gnuplot on Windows using MSVC 6.0
and the precompiled gdlib (gdwin32.zip package) I ran into
problems concerning calling convention. The supplied
bgd.dll now uses __stdcall whereas gnuplot uses __cdecl.

The attached patch fixes this issue. Could you please check
if it doesn't break anything?

Re: using bgd.dll on windows

[Ethan A M. <merritt@u.washington.edu>]

On Thursday 11 August 2005 09:06 am, Bastian Maerkisch wrote:
> While trying to compile gnuplot on Windows using MSVC 6.0
> and the precompiled gdlib (gdwin32.zip package) I ran into
> problems concerning calling convention. The supplied
> bgd.dll now uses __stdcall whereas gnuplot uses __cdecl.

I can't help with any windows testing, but I do want to point
out that gdlib itself has changed the dll mechanism between
versions, perhaps more than once.  More info on the web site 
<http://www.boutell.com/gd/>
So I worry that you risk breaking the use of one version
of libgd while 'fixing' another.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: using bgd.dll on windows

[Bastian M. <bma...@we...>]

Ethan A Merritt wrote:
> On Thursday 11 August 2005 09:06 am, Bastian Maerkisch wrote:
>=20
>>While trying to compile gnuplot on Windows using MSVC 6.0
>>and the precompiled gdlib (gdwin32.zip package) I ran into
>>problems concerning calling convention. The supplied
>>bgd.dll now uses __stdcall whereas gnuplot uses __cdecl.
>=20
>=20
> I can't help with any windows testing, but I do want to point
> out that gdlib itself has changed the dll mechanism between
> versions, perhaps more than once.  More info on the web site=20
> <http://www.boutell.com/gd/>
> So I worry that you risk breaking the use of one version
> of libgd while 'fixing' another.

According to that web site this is a "one-time breakage of
binary compatibility" introduced in version 2.0.24. As there
might still be older versions installed on a user's machine
it is probably better to just link statically (or at least
ship the latest version of bgd.dll with gnuplot).

So please forget about that patch. It will just create
another FAQ....

--=20
Bastian M=C3=A4rkisch
Physikalisches Institut, Universit=C3=A4t Heidelberg

Re: using bgd.dll on windows

[Hans-Bernhard B. <br...@ph...>]

Bastian Maerkisch wrote:
> Ethan A Merritt wrote:
>> On Thursday 11 August 2005 09:06 am, Bastian Maerkisch wrote:

>>> While trying to compile gnuplot on Windows using MSVC 6.0
>>> and the precompiled gdlib (gdwin32.zip package) I ran into
>>> problems concerning calling convention. The supplied
>>> bgd.dll now uses __stdcall whereas gnuplot uses __cdecl.

If so, then there has to be some macro or typedef exported by the GD 
headers that tells us what exactly the type of the callback functions 
has to be.  If not, that's a bug in GD which we should report, instead 
of hacking around it.

> it is probably better to just link statically (or at least
> ship the latest version of bgd.dll with gnuplot).

That would go right against some strict advice Mr. Boutell gave about 
using his library on Windows, last time I looked.  He rather strongly 
discourages anybody trying to build their own GD from sources on Windows.

Re: using bgd.dll on windows

[Bastian M. <bma...@we...>]

Hans-Bernhard Broeker wrote:
> Bastian Maerkisch wrote:
>=20
>> Ethan A Merritt wrote:
>>
>>> On Thursday 11 August 2005 09:06 am, Bastian Maerkisch wrote:
>=20
>=20
>>>> While trying to compile gnuplot on Windows using MSVC 6.0
>>>> and the precompiled gdlib (gdwin32.zip package) I ran into
>>>> problems concerning calling convention. The supplied
>>>> bgd.dll now uses __stdcall whereas gnuplot uses __cdecl.
>=20
>=20
> If so, then there has to be some macro or typedef exported by the GD=20
> headers that tells us what exactly the type of the callback functions=20
> has to be.  If not, that's a bug in GD which we should report, instead =

> of hacking around it.

Yes, there is macro:
#define BGD_DECLARE(rt) __declspec(dllimport) rt __stdcall

But this is not usable in our case because of "__declspec(dllimport)".
I sent a message to Mr. Boutell proposing a #define similar to the
one in my previous patch.

If there will be no changes to libgd and we don't want to be "hacking
around" it, we could use some intermediate functions to call
gdImagePolygon() and gdImageFilledPolygon(). The only change the
calling convention and should be eliminated by any descent optimizer.

I have implemeted this idea in the patch attached. It is still a hack,
but more reliable than the previous one.

>=20
>> it is probably better to just link statically (or at least
>> ship the latest version of bgd.dll with gnuplot).
>=20
>=20
> That would go right against some strict advice Mr. Boutell gave about=20
> using his library on Windows, last time I looked.  He rather strongly=20
> discourages anybody trying to build their own GD from sources on Window=
s.

I have looked through the documentation and the web page but could not fi=
nd
any recomendation like that. In any case using the pre-compiled version
would be much easier.

--=20
Bastian M=C3=A4rkisch
Physikalisches Institut, Universit=C3=A4t Heidelberg