[ python-Bugs-420416 ] Python for BeOS/PPC Build Prob.

SourceForge.net noreply at sourceforge.net
Mon Mar 22 17:59:36 EST 2004


Bugs item #420416, was opened at 2001-05-01 06:08
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Matthew Schinckel (schinckel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python for BeOS/PPC Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-03-22 17:59

Message:
Logged In: YES 
user_id=430343

If you still can't get it to work in 2.1 with a working autoconf, it's fixed in 
2.3.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 12:44

Message:
Logged In: YES 
user_id=6380

Thanks, Jack. I sent a msg to the autoconf list and they
said they would fix it in their CVS. Also they said:

As a workaround (so Python users don't require a CVS or
hacked version of
autoconf), you could strip '-g' from CFLAGS on BeOS (as it
seems to be that
flag that produces the .xSYM file) in configure.in.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-08-08 11:11

Message:
Logged In: YES 
user_id=45365

If I may chime in (but don't you _dare_ assign this item to
me:-): it is the AC_EXEEXT macro that fails, not AC_PROG_CC.
AC_EXEEXT just compiles and links a program, and assumes
that whatever comes out has to be the executable.

But: the Metrowerks compilers/linkers produce 2 files: the
executable (without suffix)
and the debugger symbol table (with .xSYM suffix). AC_EXEEXT
picks the wrong one:-(

Hmm, on my SGI system I can't find the definition of
AC_EXEEXT (??!?) so this is about as much help as I can
give.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 10:14

Message:
Logged In: YES 
user_id=6380

OK, thanks for the explanation.  It seems you've hit a snag
in the autoconf AC_PROG_CC macro. I don't know how
successful we'll be in getting this fixed. :-(

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-08 01:37

Message:
Logged In: NO 

[Sorry, no https: at work :-(, but it's really Matt.]

Guido, (and anyone else)

The *.xSYM file is created when the -g flag is passed to mwld, the BeOS/PPC linker, in addition to the 
executable file.

The block of the configure script that contains line 1194 is used to determine what the required executable 
extension on the current platform is.  It looks for all files in the current directory that start with conftest, 
and ignores all files that have a .c, .o or .obj extension.  It then (mistakenly, in this case) assumes that the 
file left (conftest.xSYM, and conftest; but conftest.xSYM seems to come first, or take priority) has the 
required extension. 

This is not the required extension for BeOS executables.

Since the ac_link variable has a '-o conftest${ac_exeext}' bit, it expands to -o conftest.xSYM (which, BTW, 
results in conftest.xSYM as the exe, and conftest.xSYM.xSYM as the symbol debugging file when -g is 
passed).

The sizeof(type) programs try to execute said linked program with a simple 'conftest', instead of 
'conftest${ac_exeext}, which would in fact probably work in this case.

Hence, .xSYM is not actually mentioned in the configure script, or in fact in any other file, since it is an 
artifact of the -g flag.

Which leads me to ask, what file is created by (gcc|other c compiler) when -g is passed?

I would try to work out how to fix it in configure.in, but this file still looks like gibberish to me :-)
(At least I have figured out how Makefiles and configures work - sort of)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 08:51

Message:
Logged In: YES 
user_id=6380

Matthew, please keep researching deeper.

- The case statement you want to change is inside the
expansion of the AC_PROG_CC macro; it would require a patch
to autoconf to change it the way you want.  This leads to
the following question:

- Why does the configure script use .xSYM?  This must be a
prior mistake; that string doesn't occur at all in the
configure script itself.


----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-08-06 06:52

Message:
Logged In: YES 
user_id=193059

Okay - Finally got it fixed.

change line 1149 of configure from:
      *.c | *.o | *.obj) ;;
to
      *.c | *.o | *.obj | *.xSYM) ;;

(Okay, it was the prompt from GvR that made me really get down to 
it)

Anyway, the -g flag to mwcc causes the debugging info to be put into 
a *.xSYM file, which the configure script seems to think is the 
required extension for an executable (there is none under BeOS).

Since the conftest progs for sizeof(type) have a -o conftest.xSYM, 
and the line that runs them just has a `conftest >...`, the compiled 
programs do not get run, so the size defaults to 0.

Simple.

Now I just need someone to commit this to the cvs tree...:-)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 15:44

Message:
Logged In: YES 
user_id=6380

I'm afraid it's up to Matthew to figure out why the
configure script calculates zero object sizes.  Sorry... 
(At least try Python 2.1.1, although it may not make a
difference.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-02 06:17

Message:
Logged In: YES 
user_id=38388

Assigning the bug report back to None -- someone with more knowledge about autoconf should take a look at this 
one. (It is not Unicode related.)

----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-28 06:59

Message:
Logged In: YES 
user_id=193059

Here is the crux of my recent communications with Marc-Andre:

> Okay, I might be guessing a bit here but:
> 
> These programs are supposed to print the sizeof value.
> 
> They are not printing anything.
> 
> The only error being raised is:
> 
> ### mwcc Compiler Warning :
> #       }
> #       ^
> #   return value expected
> #----------------------------------------------------------
>     File "configure"; Line 2245
> #       while compiling "/boot/var/tmp/conftest.c"
> #----------------------------------------------------------
> 

Interesting: the compiler chokes on the missing return statement
in the test program rather than some other error. This is clearly
an autoconf bug and I'm not sure whether it can be fixed in 
Python.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-23 05:20

Message:
Logged In: YES 
user_id=38388

I've uploaded Matthew's config files to SF. Perhaps some
Metroworks wizard could also take a look at these ?!

----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-22 06:12

Message:
Logged In: YES 
user_id=193059

Sorry, I've been on holiday:-)

Donn Cave gave me a patch that allows BeOS to build it, so I'll send 
it along with the config.* files...

(I've zipped them up, but I fear they will not upload with my 
browser.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 05:46

Message:
Logged In: YES 
user_id=38388

Matthew, if you can not help us here, we won't be able to
resolve the problem.

Please send us the config.* files, so that we can check
where the problem originates.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-07 07:14

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 04:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 08:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470



More information about the Python-bugs-list mailing list