[MS Windows] PVALUE causes problems with mingw64 compilers

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[MS Windows] PVALUE causes problems with mingw64 compilers

Sisyphus
Hi,

The problem arises when the mingw64 header winreg.h gets included.
We then get errors like:

C:/tmp64ng/c/include/projects.h:161:47: error: conflicting types for
'PVALUE'
  typedef union { double  f; int  i; char *s; } PVALUE;
....
C:/tmp64ng/c/x86_64-w64-mingw32/include/winreg.h:75:3: note: previous
declaration of 'PVALUE' was here
    __MINGW_TYPEDEF_AW(PVALUE)
    ^

The fairly simple (though tedious) workaround is, prior to building proj,
change each of the few occurrences of "PVALUE" in the proj source to a
symbol that doesn't clash.
(I've been using "_P_VALUE", but perhaps something like "PROJVALUE" is a
better choice .... I'm happy with *any* symbol that's not going to clash.)

Could the proj developers please rename "PVALUE" to something that doesn't
clash ?
I really would like to not have to alter the proj source in future proj
releases.

I did raise this matter a few years ago but, as nothing was ever done, I
thought that maybe I should instead submit a bug report along with a patch.
However, AFAICT, to submit a bug report I need to go to
http://www.osgeo.org/osgeo_userid/ and create a user id so that I can first
log in.

Unfortunately the link to "this simple form" (
https://www.osgeo.org/cgi-bin/ldap_create_user.py ) results in a "page can't
be displayed error" for me.
There's a suggestion there that this could be a problem with my browser
settings, though I don't usually have any trouble with secure connections.

Is there any other way I can create a user id ?

Cheers,
Rob

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: [MS Windows] PVALUE causes problems with mingw64 compilers

Howard Butler-3

> On May 19, 2015, at 3:46 AM, [hidden email] wrote:
>
> Hi,
>
> The problem arises when the mingw64 header winreg.h gets included.
> We then get errors like:
>
> C:/tmp64ng/c/include/projects.h:161:47: error: conflicting types for
> 'PVALUE'
>  typedef union { double  f; int  i; char *s; } PVALUE;
> ....
> C:/tmp64ng/c/x86_64-w64-mingw32/include/winreg.h:75:3: note: previous
> declaration of 'PVALUE' was here
>    __MINGW_TYPEDEF_AW(PVALUE)
>    ^
>
> The fairly simple (though tedious) workaround is, prior to building proj,
> change each of the few occurrences of "PVALUE" in the proj source to a
> symbol that doesn't clash.
> (I've been using "_P_VALUE", but perhaps something like "PROJVALUE" is a
> better choice .... I'm happy with *any* symbol that's not going to clash.)
>
> Could the proj developers please rename "PVALUE" to something that doesn't
> clash ?
> I really would like to not have to alter the proj source in future proj
> releases.
>
> I did raise this matter a few years ago but, as nothing was ever done, I
> thought that maybe I should instead submit a bug report along with a patch.
> However, AFAICT, to submit a bug report I need to go to
> http://www.osgeo.org/osgeo_userid/ and create a user id so that I can first
> log in.
>
> Unfortunately the link to "this simple form" (
> https://www.osgeo.org/cgi-bin/ldap_create_user.py ) results in a "page can't
> be displayed error" for me.
> There's a suggestion there that this could be a problem with my browser
> settings, though I don't usually have any trouble with secure connections.
>
> Is there any other way I can create a user id ?

The https://www.osgeo.org/cgi-bin/ldap_create_user.py page is up for me at  this time.

I have created a ticket with this issue at http://trac.osgeo.org/proj/ticket/273 but I do not know if it is practical to change this union name from PVALUE to something else in what is essentially a public header. Does anyone else have an opinion?

Howard
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: [MS Windows] PVALUE causes problems with mingw64 compilers

Even Rouault-2
Le mardi 19 mai 2015 19:03:01, Howard Butler a écrit :

> > On May 19, 2015, at 3:46 AM, [hidden email] wrote:
> >
> > Hi,
> >
> > The problem arises when the mingw64 header winreg.h gets included.
> > We then get errors like:
> >
> > C:/tmp64ng/c/include/projects.h:161:47: error: conflicting types for
> > 'PVALUE'
> >
> >  typedef union { double  f; int  i; char *s; } PVALUE;
> >
> > ....
> > C:/tmp64ng/c/x86_64-w64-mingw32/include/winreg.h:75:3: note: previous
> > declaration of 'PVALUE' was here
> >
> >    __MINGW_TYPEDEF_AW(PVALUE)
> >    ^
> >
> > The fairly simple (though tedious) workaround is, prior to building proj,
> > change each of the few occurrences of "PVALUE" in the proj source to a
> > symbol that doesn't clash.
> > (I've been using "_P_VALUE", but perhaps something like "PROJVALUE" is a
> > better choice .... I'm happy with *any* symbol that's not going to
> > clash.)
> >
> > Could the proj developers please rename "PVALUE" to something that
> > doesn't clash ?
> > I really would like to not have to alter the proj source in future proj
> > releases.
> >
> > I did raise this matter a few years ago but, as nothing was ever done, I
> > thought that maybe I should instead submit a bug report along with a
> > patch. However, AFAICT, to submit a bug report I need to go to
> > http://www.osgeo.org/osgeo_userid/ and create a user id so that I can
> > first log in.
> >
> > Unfortunately the link to "this simple form" (
> > https://www.osgeo.org/cgi-bin/ldap_create_user.py ) results in a "page
> > can't be displayed error" for me.
> > There's a suggestion there that this could be a problem with my browser
> > settings, though I don't usually have any trouble with secure
> > connections.
> >
> > Is there any other way I can create a user id ?
>
> The https://www.osgeo.org/cgi-bin/ldap_create_user.py page is up for me at
> this time.
>
> I have created a ticket with this issue at
> http://trac.osgeo.org/proj/ticket/273 but I do not know if it is practical
> to change this union name from PVALUE to something else in what is
> essentially a public header. Does anyone else have an opinion?

A workaround for user code would possibly be to #define
_PROVIDER_STRUCTS_DEFINED before including winreg.h or anything that includes
it, since the PVALUE stuff seems to be conditionnaly defined by that (I did not
try)

Otherwise projects.h has always had a semi-public/semi-private status, so that
might be OK to change that. PVALUE is only used as the return type of
pj_param(projCtx ctx, paralist *, const char *);

>
> Howard
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: [MS Windows] PVALUE causes problems with mingw64compilers

Sisyphus
-----Original Message-----
From: Even Rouault
Sent: Wednesday, May 20, 2015 4:03 AM
To: [hidden email]
Subject: Re: [Proj] [MS Windows] PVALUE causes problems with
mingw64compilers

> Le mardi 19 mai 2015 19:03:01, Howard Butler a écrit :
>>> On May 19, 2015, at 3:46 AM, [hidden email] wrote:

>>> Is there any other way I can create a user id ?
>>
>> The https://www.osgeo.org/cgi-bin/ldap_create_user.py page is up for me
>> at
>> this time.

Still not working with IE, but works fine on Ubuntu using Firefox.

>> I have created a ticket with this issue at
>> http://trac.osgeo.org/proj/ticket/273 but I do not know if it is
>> practical
>> to change this union name from PVALUE to something else in what is
>> essentially a public header.

Damn ... I should've raised this during that recent brief period when
projects.h
was classified as private ;-))

> A workaround for user code would possibly be to
> #define _PROVIDER_STRUCTS_DEFINED
> before including winreg.h or anything that includes it, since the PVALUE
> stuff seems to be conditionnaly defined by that (I did not try)

This problem comes up when building the PDL::GIS::Proj (perl) module.
On Windows, it's inevitable that the building of this perl extension will
include windows.h - and hence winreg.h

I've just tried the suggestion of defining _PROVIDER_STRUCTS_DEFINED, but
that causes other winreg.h errors:

winreg.h:181:59: error: unknown type name 'PVALENTA'
winreg.h:182:59: error: unknown type name 'PVALENTW'

Those symbols are also defined in winreg.h if _PROVIDER_STRUCTS_DEFINED is
not already defined.

> Otherwise projects.h has always had a semi-public/semi-private status, so
> that might be OK to change that. PVALUE is only used as the return type of
> pj_param(projCtx ctx, paralist *, const char *);

Is it worth going to the trouble of changing the PVALUE symbol to (say)
PROJVALUE for mingw compilers only - but letting the PVALUE symbol stand
with non-mingw compilers:

#ifdef __MINGW32__  */ All mingw compilers */
/* code uses PROJVALUE symbol */
#else
/* code uses PVALUE symbol */
#endif

That would significantly lessen the chances of upsetting those who have been
using PVALUE in their own code.

I think I could provide patches for that, if it's an acceptable option.
However, I'm not sure it's such a good idea to start splitting up code like
that.

Cheers,
Rob

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: [MS Windows] PVALUE causes problems with mingw64compilers

Howard Butler-3

> On May 21, 2015, at 5:04 AM, [hidden email] wrote:
>
>
> Is it worth going to the trouble of changing the PVALUE symbol to (say)
> PROJVALUE for mingw compilers only - but letting the PVALUE symbol stand
> with non-mingw compilers:

I don’t think so. I think it should just be changed. The folks using projects.h have known it was a bit sketchy to be using (we tried to take it away once already). The next windows person using proj.4 with an interesting include scenario will run into again if we monkey patch the mingw case only.

Let’s just rename it, unless someone has a strong objection.

Howard

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: [MS Windows] PVALUE causes problems with mingw64compilers

Sisyphus
-----Original Message-----
From: Howard Butler
Sent: Thursday, May 21, 2015 10:43 PM
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] [MS Windows] PVALUE causes problems with
mingw64compilers


>> On May 21, 2015, at 5:04 AM, [hidden email] wrote:
>>
>>
>> Is it worth going to the trouble of changing the PVALUE symbol to (say)
>> PROJVALUE for mingw compilers only - but letting the PVALUE symbol stand
>> with non-mingw compilers:
>
> I don’t think so. I think it should just be changed. The folks using
> projects.h have known it was a bit sketchy to be using (we tried to take
> it away once already). The next windows person using proj.4 with an
> interesting include scenario will run into again if we monkey patch the
> mingw case only.
>
> Let’s just rename it, unless someone has a strong objection.

Renaming it is *definitely* my preferred option.

However, following on from an idea presented by David Mertens on the
pdl-devel mailing list, I do have a slight refinement to the above idea of
allowing 2 symbols.

Change:

typedef union { double  f; int  i; char *s; } PVALUE;

to something like:

typedef union { double  f; int  i; char *s; } PROJVALUE;

and then insert:

/* The following is for backwards compatibility. */
/* PVALUE is deprecated - use PROJVALUE       */
#ifndef _WINREG_ /* _WINREG_ is defined by winreg.h */
#define PVALUE PROJVALUE
#endif

And then, in the proj source, replace all other instances of PVALUE with
PROJVALUE.
Also document PVALUE as being deprecated and will be removed in a future
release.

The only problem is that it still enables someone to write source code that
uses PVALUE - and that source code therefore does not run on Windows if
winreg.h is included.
But, if PVALUE is documented as being deprecated, we presumably open the
door to being able to remove it at a future date (without being accused of
doing something we shouldn't do).
In the meantime it's unlikely that anyone will be inconvenienced.

Cheers,
Rob

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj