Issue420416
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2001-05-01 10:08 by schinckel, last changed 2022-04-10 16:04 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
config.log | lemburg, 2001-05-23 09:16 | Config log file showing the problem | ||
config.h | lemburg, 2001-05-23 09:18 | config.h with the 0 defines for SIZEOF_LONG etc. |
Messages (17) | |||
---|---|---|---|
msg4584 - (view) | Author: Matthew Schinckel (schinckel) | Date: 2001-05-01 10:08 | |
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. |
|||
msg4585 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2001-05-02 12:50 | |
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 ? |
|||
msg4586 - (view) | Author: Matthew Schinckel (schinckel) | Date: 2001-05-07 08:20 | |
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? |
|||
msg4587 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2001-05-07 11:14 | |
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. |
|||
msg4588 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2001-05-21 09:46 | |
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. |
|||
msg4589 - (view) | Author: Matthew Schinckel (schinckel) | Date: 2001-05-22 10:12 | |
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.) |
|||
msg4590 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2001-05-23 09:20 | |
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 ?! |
|||
msg4591 - (view) | Author: Matthew Schinckel (schinckel) | Date: 2001-05-28 10:59 | |
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. |
|||
msg4592 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2001-08-02 10:17 | |
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.) |
|||
msg4593 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-08-02 19:44 | |
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.) |
|||
msg4594 - (view) | Author: Matthew Schinckel (schinckel) | Date: 2001-08-06 10:52 | |
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...:-) |
|||
msg4595 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-08-06 12:51 | |
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. |
|||
msg4596 - (view) | Author: Nobody/Anonymous (nobody) | Date: 2001-08-08 05:37 | |
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) |
|||
msg4597 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-08-08 14:14 | |
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. :-( |
|||
msg4598 - (view) | Author: Jack Jansen (jackjansen) * | Date: 2001-08-08 15:11 | |
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. |
|||
msg4599 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-08-08 16:44 | |
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. |
|||
msg4600 - (view) | Author: Nick Bastin (nbastin) * | Date: 2004-03-22 22:59 | |
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. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:04:01 | admin | set | github: 34440 |
2001-05-01 10:08:19 | schinckel | create |