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

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.

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

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:

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 ?

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