Re: pyrex error

Discussion in 'Python' started by Austin Luminais, Aug 2, 2003.

  1. "Bryan" <> wrote in message news:<B4IWa.45665$uu5.4763@sccrnsc04>...
    > i'm having trouble building the pyrex demos. i also can't compile a simple
    > hello word example. i keep getting this '__pyx_f' unknown size error.
    > here's the error i'm getting when executing the following script.
    >
    > i'm using vc 6.0 on windows xp
    > python 2.3
    >


    I've been experiencing the same problem since upgrading python to 2.3.
    I think the definition of "staticforward" must have been changed.

    A temporary fix that seems to work (with MSVC 6.0) is changing this
    line in the generated code:

    staticforward char *__pyx_f[];

    to:

    extern char *__pyx_f[];
     
    Austin Luminais, Aug 2, 2003
    #1
    1. Advertising

  2. Austin Luminais

    Bryan Guest

    thank you... i worked.


    "Austin Luminais" <> wrote in message
    news:...
    > "Bryan" <> wrote in message

    news:<B4IWa.45665$uu5.4763@sccrnsc04>...
    > > i'm having trouble building the pyrex demos. i also can't compile a

    simple
    > > hello word example. i keep getting this '__pyx_f' unknown size error.
    > > here's the error i'm getting when executing the following script.
    > >
    > > i'm using vc 6.0 on windows xp
    > > python 2.3
    > >

    >
    > I've been experiencing the same problem since upgrading python to 2.3.
    > I think the definition of "staticforward" must have been changed.
    >
    > A temporary fix that seems to work (with MSVC 6.0) is changing this
    > line in the generated code:
    >
    > staticforward char *__pyx_f[];
    >
    > to:
    >
    > extern char *__pyx_f[];
     
    Bryan, Aug 2, 2003
    #2
    1. Advertising

  3. Bryan wrote:
    > [PyRex produces code using staticforward that won't work in the combination Python 2.3/MSVC]


    1) Please don't top-post.

    2) The other way to temporarily solve this problem is to use MINGW
    instead of MSVC.

    In the PySQLite sources, I added this snippet on top:

    #ifdef _MSC_VER
    #define staticforward extern
    #endif

    to make it compilable under MSVC/Python 2.3. *After* #include-ing
    "Pyhton.h" of course.

    -- Gerhard
     
    =?ISO-8859-1?Q?Gerhard_H=E4ring?=, Aug 2, 2003
    #3
  4. Austin Luminais

    John Machin Guest

    Gerhard Häring <> wrote in message news:<>...
    > Bryan wrote:
    > > [PyRex produces code using staticforward that won't work in the combination Python 2.3/MSVC]


    > 2) The other way to temporarily solve this problem is to use MINGW
    > instead of MSVC.


    *One* other way, not *the* other way. If the OP wanted to muck about
    downloading and becoming familiar with a different compiler, he could
    also try the free Borland compiler.

    And here is a third, easier other way: fiddle with your
    .....\include\object.h so that it defines staticforward as extern.

    It appears we have a change from 2.2 to 2.3 that breaks extensions
    compiled with the MS C compiler, which is used to build the win32
    version of Python ...
    say it ain't so, Joe!

    ==== from v2.2 object.h ====
    /*
    A common programming style in Python requires the forward declaration
    of static, initialized structures, e.g. for a type object that is used
    by the functions whose address must be used in the initializer.
    Some compilers (notably SCO ODT 3.0, I seem to remember early AIX as
    well) botch this if you use the static keyword for both declarations
    (they allocate two objects, and use the first, uninitialized one until
    the second declaration is encountered). Therefore, the forward
    declaration should use the 'forwardstatic' keyword. This expands to
    static on most systems, but to extern on a few. The actual storage
    and name will still be static because the second declaration is
    static, so no linker visible symbols will be generated. (Standard C
    compilers take offense to the extern forward declaration of a static
    object, so I can't just put extern in all cases. :-( )
    */

    #ifdef BAD_STATIC_FORWARD
    #define staticforward extern
    #define statichere static
    #else /* !BAD_STATIC_FORWARD */
    #define staticforward static
    #define statichere static
    #endif /* !BAD_STATIC_FORWARD */
    ==== from v2.3 object.h ====
    /*
    Define staticforward and statichere for source compatibility with old
    C extensions.

    The staticforward define was needed to support certain broken C
    compilers (notably SCO ODT 3.0, perhaps early AIX as well) botched the
    static keyword when it was used with a forward declaration of a static
    initialized structure. Standard C allows the forward declaration with
    static, and we've decided to stop catering to broken C compilers.
    (In fact, we expect that the compilers are all fixed eight years
    later.)
    */

    #define staticforward static
    #define statichere static
     
    John Machin, Aug 4, 2003
    #4
  5. Austin Luminais

    John Machin Guest

    On 4 Aug 2003 05:04:20 -0700, (John Machin)
    wrote:

    >Gerhard Häring <> wrote in message news:<>...
    >> Bryan wrote:
    >> > [PyRex produces code using staticforward that won't work in the combination Python 2.3/MSVC]

    >
    >> 2) The other way to temporarily solve this problem is to use MINGW
    >> instead of MSVC.

    >
    >*One* other way, not *the* other way. If the OP wanted to muck about
    >downloading and becoming familiar with a different compiler, he could
    >also try the free Borland compiler.
    >
    >And here is a third, easier other way: fiddle with your
    >....\include\object.h so that it defines staticforward as extern.
    >


    and here is a fourth easier other way: fiddle with Pyrex itself:
    change staticforward to extern in line 169 of Nodes.py

    C:\sw\pyrex\Pyrex-0.8.2\Pyrex\Compiler>grep -n staticforward *.py
    Nodes.py:169: code.putln('staticforward char *%s[];' %
    Naming.filetable_cname)
    Nodes.py:263: code.putln("staticforward PyTypeObject %s;" %
    name)
     
    John Machin, Aug 4, 2003
    #5
  6. Austin Luminais

    Bryan Guest

    "John Machin" <> wrote in message news:...
    > "Bryan" <> wrote in message news:<7NtXa.62774$uu5.6090@sccrnsc04>...
    > > "Gerhard Häring" <> wrote in message news:...
    > > > Bryan wrote:
    > > > > [PyRex produces code using staticforward that won't work in the combination Python 2.3/MSVC]

    >
    > > > In the PySQLite sources, I added this snippet on top:
    > > >
    > > > #ifdef _MSC_VER
    > > > #define staticforward extern
    > > > #endif
    > > >
    > > > to make it compilable under MSVC/Python 2.3. *After* #include-ing
    > > > "Pyhton.h" of course.

    >
    > > i've decided to go with gerhard's approach with one minor modification:
    > >
    > > #ifdef _MSC_VER
    > > #undef staticforward
    > > #define staticforward extern
    > > #endif
    > >
    > > this solution is best for me because i want to take the resulting c file and give it to others so they can compile it on other

    OS's
    > > and compilers.
    > >
    > > why can't this code be placed in the pyrex header? seems like a simple fix.

    >
    > What gave you the impression that it can't be put in? You tell us why
    > *you* can't put it in.
    >


    because i don't have the experience to do so. the fact you think the above #ifdef is a kludge proves it and i'm not even the one
    who came up with those 4 lines.

    > I'll tell you why it *shouldn't* be put in: because it's a kludge. The
    > offending C code is a forward declaration of a char [] which is
    > subsequently filled in with the name of the source .pyx file which is
    > known at the time the staticforward is emitted. The principled fix is
    > to declare and define the array in one hit.
     
    Bryan, Aug 5, 2003
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gregarius

    ANN: Pyrex 0.8.1

    Gregarius, Jun 29, 2003, in forum: Python
    Replies:
    0
    Views:
    684
    Gregarius
    Jun 29, 2003
  2. Simon Burton

    pyrex.vim ?

    Simon Burton, Aug 21, 2003, in forum: Python
    Replies:
    2
    Views:
    413
    David M. Cooke
    Aug 21, 2003
  3. =?iso-8859-1?Q?Fran=E7ois?= Pinard

    Re: Pyrex without Python (was Re: calling Pyrex results from C)

    =?iso-8859-1?Q?Fran=E7ois?= Pinard, Jan 21, 2004, in forum: Python
    Replies:
    3
    Views:
    328
    A.M. Kuchling
    Jan 21, 2004
  4. Chris Lambacher
    Replies:
    0
    Views:
    682
    Chris Lambacher
    Jun 8, 2005
  5. Greg Ewing
    Replies:
    2
    Views:
    367
    Dieter Maurer
    Jun 29, 2006
Loading...

Share This Page