Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Authentication-Warning: slinky.cs.nyu.edu: pechtcha owned process doing -bs
Date: Thu, 2 Jan 2003 15:03:21 -0500 (EST)
From: Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: Jason Tishler <jason AT tishler DOT net>
cc: cygwin AT cygwin DOT com
Subject: Re: Cygwin gcc "initializer element is not constant" problem
In-Reply-To: <20030102163008.GF1524@tishler.net>
Message-ID: <Pine.GSO.4.44.0301021457290.8991-200000@slinky.cs.nyu.edu>
Importance: Normal
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_SaDdXNl29QRKLrUMrAEssQ)"
Content-ID: <Pine DOT GSO DOT 4 DOT 44 DOT 0301021457291 DOT 8991 AT slinky DOT cs DOT nyu DOT edu>

--Boundary_(ID_SaDdXNl29QRKLrUMrAEssQ)
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine DOT GSO DOT 4 DOT 44 DOT 0301021457292 DOT 8991 AT slinky DOT cs DOT nyu DOT edu>
Content-Disposition: INLINE

On Thu, 2 Jan 2003, Jason Tishler wrote:

> The attached code snippet, j2.c, demonstrates a Cygwin specific
> compilation problem that affects many Python shared extension modules:
>
>     $ gcc -c j2.c
>     j2.c:17: initializer element is not constant
>     j2.c:17: (near initialization for `f.get')
>
> It appears that Cygwin gcc considers function pointers marked
> "__declspec(dllimport)" unacceptable to use as initializer constants.
>
> My standard workaround is to submit a patch that is the equivalent of
> compiling this snippet with -DWORKAROUND:
>
>     $ gcc -DWORKAROUND -c j2.c
>
> Unfortunately, this style of patch is no longer acceptable:
>
>     http://mail.python.org/pipermail/python-dev/2002-December/031534.html
>
> Can anyone suggest a better (hopefully less intrusive) workaround?
>
> Thanks,
> Jason

Jason,

I believe the complaint was not about the intrusiveness (i.e. patch size)
of the workaround, but about the readability of the resulting code.

How about doing exactly what the message suggests (see attached)?
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor AT watson DOT ibm DOT com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune

--Boundary_(ID_SaDdXNl29QRKLrUMrAEssQ)
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="j2-modified.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine DOT GSO DOT 4 DOT 44 DOT 0301021503210 DOT 8991 AT slinky DOT cs DOT nyu DOT edu>
Content-Description: 
Content-Disposition: attachment; filename="j2-modified.c"

I2lmbmRlZiBXT1JLQVJPVU5EDQojICBkZWZpbmUgSU5JVElBTCh2KSAodikN
CiMgIGRlZmluZSBBU1NJR04oZix2KQ0KI2Vsc2UNCiMgIGRlZmluZSBJTklU
SUFMKHYpICgwKQ0KIyAgZGVmaW5lIEFTU0lHTihmLHYpIGRveyBmID0gdjsg
fXdoaWxlKDApDQojZW5kaWYNCg0KdHlwZWRlZiB2b2lkICgqZnVuY3Rpb24p
KCk7DQoNCnN0cnVjdCBmb28NCnsNCiAgICAgICAgZnVuY3Rpb24gZ2V0Ow0K
fTsNCg0KX19kZWNsc3BlYyhkbGxpbXBvcnQpIHZvaWQgZjEoKTsNCg0Kc3Ry
dWN0IGZvbyBmID0NCnsNCiAgICAgICAgSU5JVElBTChmMSkNCn07DQoNCnZv
aWQNCmluaXQoKQ0Kew0KICAgICAgICBBU1NJR04oZi5nZXQsIGYxKTsNCn0N
Cg0K

--Boundary_(ID_SaDdXNl29QRKLrUMrAEssQ)
Content-Type: text/plain; charset=us-ascii

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/
--Boundary_(ID_SaDdXNl29QRKLrUMrAEssQ)--