...

...

...

...

"MvL" == Martin v Loewis writes:

MvL> I don't think we can get autoconf detection to work on MvL> 2.1. I don't mind. MvL> The instructions are right. Unfortunately, the code is MvL> wrong: It prefers fgetpos in 2.1, but that returns not an MvL> integral type on some systems. Right. MvL> I think the best approach is to copy the body of MvL> _portable_fseek and _portable_ftell from 2.2. With that, I MvL> get a setup that atleast looks right (patch attached) Unfortunately that's not enough, I suspect. >> I've had some failures on 2.4.7 kernels w/ ext3 filesystems. MvL> Were these compilation failures, or runtime failures? For the MvL> compilation failures, ext3 should be irrelevant, and 2.4.7 MvL> should be irrelevant as well - the glibc version would matter MvL> (which defines fpos_t to be a struct with an mbstate_t MvL> inside). Vanilla release21-maint will give compilation failures, which go away with the patch (essentially what I tried on other systems). But even with these patches, test_largefile fails on the seek(2**31L). So something else too is going on. FTR: this is a stock Mandrake 8.1 system w/ glibc 2.2.4. I don't have much time to spend looking into this right now, but it would be good to fix for 2.1.2. -Barry

...

...

...

...

"CM" == Chris McDonough writes:

CM> I'm subscribed to the list, but I'm still not quite sure if CM> I'm supposed to be posting here... I suppose I should go read CM> the charter. Please flame me if this list is for the "in CM> crowd" only. ;-) You did fine, Chris! :) Welcome. CM> I tried to get the 21-maintbranch LFS working using the CM> directions that are provided in the current docs CM> (http://www.python.org/doc/current/lib/posix-large-files.html), CM> but it fails to compile for me as a result. Someone has CM> suggested that it's not the instructions that are broken, but CM> the code. Can this be confirmed? Confirmed. The compilation errors can be fixed with the patch that Martin sent around earlier in this thread. So that probably ought to be added to Python 2.1.2. But the patch + the posix-large-file instructions still don't enable large file support for me on glibc 2.2.4. So something more is needed. CM> Because ZC is forced to stick with Python 2.1.X (as opposed to CM> 2.2.X) for the current crop of Zope releases, and because we CM> often need large file support under Zope, it's pretty CM> important for us to get a 2.1.X release under which LFS works. CM> A workaround is fine as well. CM> I don't think I have the knowhow to fix it, but if I can help CM> in any way by testing under various Linuxii, please let me CM> know. I do plan to get back to this if nobody else fixes it in the meantime, but I've got a couple of higher priority things to deal with right now. I'd say LFS in Python 2.1.2 should be a high priority. -Barry

----- Original Message ----- From: "Guido van Rossum" To: "Barry A. Warsaw" Cc: "Chris McDonough" ; "Martin v. Loewis" ; ; Sent: Friday, January 04, 2002 14:04 Subject: Re: [Python-Dev] release for 2.1.2, plus 2.2.1...

...

Confirmed. The compilation errors can be fixed with the patch that Martin sent around earlier in this thread. So that probably ought to be added to Python 2.1.2. But the patch + the posix-large-file instructions still don't enable large file support for me on glibc 2.2.4. So something more is needed.

Hm, is it possible that glibc 2.2.4 is too old to support large files? s I would be surprised if glibc 2.2.4 does not support LFS. Some months ago I installed Python 2.1 on a "older" RH 7.1 system with LFS support. The glibc version of RH7.1 is most likely older than 2.2.4.

Andreas

Hm, is it possible that glibc 2.2.4 is too old to support large files?

No, it is the current release. Regards, Martin

Confirmed. The compilation errors can be fixed with the patch that Martin sent around earlier in this thread. So that probably ought to be added to Python 2.1.2. But the patch + the posix-large-file instructions still don't enable large file support for me on glibc 2.2.4. So something more is needed.

One possible difference between your and my installation is that you probably followed the Linux instructions, whereas I followed the Solaris instructions (even though my system is Linux). I did so because of martin@mira:~/work/python/dist/src> getconf LFS_CFLAGS -D_FILE_OFFSET_BITS=64 So getconf works fine on Linux, as well, and DTRT. Could please recompile your installation using the getconf approach alone?

I do plan to get back to this if nobody else fixes it in the meantime, but I've got a couple of higher priority things to deal with right now.

I'd say LFS in Python 2.1.2 should be a high priority.

I'd like to see an independent confirmation first that there still is a problem to solve. Regards, Martin

Martin> I don't like it when people post questions of the "how do I Martin> ... in Python" kind that you typically see on python-list - this Martin> is not a list to get better help :-) Somewhat au contraire from this neck of the woods... In my Unicode filename thread I decided it would be best to post here for a couple reasons: * I figured most good answers would come from Martin and Marc-Andrè. * It's not clear that the "right way" to do this stuff appears to be settled, which I think has been proven out somewhat by the extended thread and the long thread Jack started about Unicode and getargs.c. Skip

Well, you did not describe exactly how it fails to compile for you. Assuming you got an error that something is not an integral type, then that is clearly an error in the code. You might want to investigate the error message you get more closely; please confirm that it refers to the return value of fgetpos.

Yes, apologies. I should have provided more details. I'm using a stock Red Hat Linux 7.2, which has glibc 2.2.4 (Linux kernel version 2.4.7). With a Python built successfully from the 21-maintbranch without any additional compiler flags indicating that I want large file support, I get this when attempting to run the test_largefile test: [chrism@kurtz tmp]$ python /usr/local/lib/python2.1/test/test_largefile.py Traceback (most recent call last): File "/usr/local/lib/python2.1/test/test_largefile.py", line 22, in ? raise test_support.TestSkipped, \ test_support.TestSkipped: platform does not have largefile support What's going on "under the hood" here is that a bit of code like this: open('foo', 'w').seek(2147483649L) .. raises an IOError 22, (invalid argument) out of the seek. When I attempt to compile the code from the same branch using the instructions for Solaris from http://www.python.org/doc/current/lib/posix-large-files.html, it craps out during a successive make: gcc -c -g -O2 -I. -I./Include -DHAVE_CONFIG_H -o Objects/fileobject.o Objects/fileobject.c Objects/fileobject.c: In function `_portable_ftell': Objects/fileobject.c:267: incompatible types in return make: *** [Objects/fileobject.o] Error 1 [chrism@kurtz src]$ As a result, I am not able to compile successfully. (Note: FYI, the same thing happens when following the slightly different current doc instructions for Linux.) So be it. With the patch you supplied earlier (and providing *either* the "Solaris" or "Linux" largefile support flags to configure) I am able to compile successfully and when invoking the resulting executable against test_largefile.py, I get what looks like success, e.g.: create large file via seek (may be sparse file) ... 2500000001L =?= 2500000001L ... yes check file size with os.fstat check file size with os.stat 2500000001L =?= 2500000001L ... yes play around with seek() and read() with the built largefile 0L =?= 0 ... yes .... So the question is this: is there reason to disbelieve test_largefile? There seems to be some disbelief from Barry that your patch is "enough", but it appears to work at least enough to fool test_largefile. ;-) - C

...

...

...

...

"MvL" == Martin v Loewis writes:

MvL> I don't know how Barry found that the tests fail, but must MvL> likely, one of the expect calls failed, resulting in a MvL> TestFailed exception - which would have been clearly visible. Okay, it's a build problem. For whatever reason, the -D flags set in configure weren't getting passed to gcc during the make. If I add that explicitly, everything works. So Py2.1.2 is fine with Martin's patch, which should be committed to the maint branch. If I come up with a better recipe for posix-large-files I'll submit it as a doc-fix. -Barry

Barry A. Warsaw writes:

CC is propagated to the Makefile so that just "make" is necessary, but OPT and CFLAGS is not. (Although, I seem to vaguely remember that OPT /used/ to propagate -- I must be mis-remebering.)

Or it used to work -- that's how I remember it as well. Perhaps we should fix this. Feel free to file a bug report and assign it to me. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

...

...

...

...

...

"Fred" == Fred L Drake, Jr writes:

Fred> Or it used to work -- that's how I remember it as well. Fred> Perhaps we should fix this.

It looks like OPT propagates in Python2.2-cvs, e.g. try:

% OPT=-g ./configure

So maybe it's just a bug in release21-maint.

Fred> Feel free to file a bug report and assign it to me.

Done.

Before changing the documentation, I'd like to understand the problem Barry is seeing first, or I'd like to hear independent confirmation that the docs have a bug. Chris' report, in http://mail.python.org/pipermail/python-dev/2002-January/019177.html is contradicting: On one hand, he says that following the instructions, he got an interpreter that does LFS correctly; but he also says that the compilation line is just gcc -c -g -O2 -I. -I./Include -DHAVE_CONFIG_H -o Objects/fileobject.o which cannot possibly have the desired effect, AFAICT. Regards, Martin

...

...

...

...

"MvL" == Martin v Loewis writes:

MvL> What version of configure are you using? On my system, with MvL> configure 1.207.2.7, doing 1.207.2.7 is at the head of the release21-maint branch, so that's definitely the version I'm using. MvL> CFLAGS='-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64' OPT="-g MvL> -O2 $CFLAGS" ./configure MvL> will result in a line MvL> OPT= -g -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 MvL> in the Makefile. Not for me. In fact the -D symbols never make it into the Makefile at all. MvL> This, in turn, will result in a compilation MvL> line MvL> gcc -c -g -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 MvL> -I. -I./Include -DHAVE_CONFIG_H -o Objects/fileobject.o MvL> Objects/fileobject.c MvL> Something else is going on on your system. Did you remove MvL> config.cache before running configure? Of course! I always "make distclean" before running configure again. -Barry

...

...

...

...

"MvL" == Martin v Loewis writes:

MvL> That is very puzzling. I just did a fresh checkout on MvL> cf.sf.net (the debian installation), using MvL> Can you please try the same sequence of actions on the SF MvL> compile farm, and report what it does for you? Alternatively, MvL> can you spot the error in the commands I used? Actually, let's do something different. My laptop is a pretty stock Mandrake 8.1 installation, while my desktop is a RH 6.1-ish system (with a few kernel and other package updates). On a fresh checkout of the release21-maint branch on the RH system, everything works fine; the posix-large-file recipe does indeed propagate the extended OPT macro into the Makefile. A fresh checkout on the Mandrake system it does not. Weird. What's different? On both systems we're using autoconf 2.13, and m4 version 1.4. On the RH system I've got GNU make version 3.77, but on Mandrake it's 3.79.1 so that's one obvious difference. But I'd be surprised if this is a make bug because I didn't think make was invoked during the configure phase. I've gotta run, but I'll try to look into this some more later on. -Barry

...

...

...

...

"MvL" == Martin v Loewis writes:

MvL> Right. That leaves it to /bin/sh. Yup. A bash bug? /bin/sh (aka bash) version 2.03.8 on RH6.1 vs. 2.05.1 on MD8.1. It isn't sed, which is at version 3.02 on both. Hmm, a bash bug? -Barry

Okay, I'm totally confuggled now. Let's boil this down. Take this simple program: -------------------- snip snip --------------------/tmp/foo.sh #! /bin/sh echo "OPT = x${OPT}x" echo "CFLAGS= x${CFLAGS}x" -------------------- snip snip -------------------- and invoke it like: % CFLAGS='one' OPT="two $CFLAGS" /tmp/foo.sh What do you get? What do you *expect* to get? Am I boiling things down correctly? On every system I've tested, the following output is what I get: % CFLAGS='one' OPT="two $CFLAGS" /tmp/foo.sh OPT = xtwo x CFLAGS= xonex So, why should any of this work anywhere? Should we ever expect $OPT to get the right value? i-must-be-missing-something-really-obvious,-obvious-ly y'rs, -Barry

I haven't followed this, but from the above it appears that if you use the form

VAR1=val1 VAR2=val2 ... program args

then all of val1, val2, ... are evaluated simultaneously using the previous values of VAR1, VAR2, ... rather than left-to-right.

That's mildly surprising but not really upsetting to me.

What *is* upsetting is that different shells behave differently; or else the current documentation would not have been written the way it is now (and Barry and me would not have spent the week-end researching that). Recent bash versions, and Korn shell evaluate from left to right (bash now documents that assignments occur *after* args have been expanded). Regards, Martin

...

...

...

...

"NN" == Neal Norwitz writes:

NN> I think the intent was to use single quotes for OPT='two NN> $CFLAGS'. (You could also do OPT="two \$CFLAGS".) This will NN> pass the string "$CFLAGS" in OPT, not the value of the shell NN> variable $CFLAGS. NN> While your shell script will print out: OPT = xtwo $CFLAGSx NN> This is ok since it will/should get expanded properly in the NN> Makefile. Unfortunately, none of this really helps. Getting $(CFLAGS) into $OPT just results in this: Makefile:737: *** Recursive variable `CFLAGS' references itself (eventually). Stop. Let me suggest the following, and then I'm going to stop here. Martin's patch to fileobject.c should be applied -- that's a given. As for configure: CC='gcc -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64' ./configure works for me. I'll leave it up to others to decide what to change, although IMHO posix-large-file is broken (and also because those instructions shouldn't be necessary for Python 2.2). -Barry

...

CC='gcc -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64' ./configure

That's good enough for me - I'll test it on the boxes I can find...

I'd strongly advise against putting that into the documentation. There are numerous assignments to CC inside configure.in, which would override this setting. Setting OPT and CFLAGS is the right way to pass these configuration options.

...

I'll leave it up to others to decide what to change,

Documentation?

Please, not the way Barry proposes. Regards, Martin

Barry A. Warsaw writes:

Here's another suggestion: add a make variable that isn't used or anything else, has a default empty value, and is used to create the compilation command. Let's say $LARGEFILE.

This seems tolerable. We should probably look for getconf in the configure script, and make the default value the result of "getconf LFS_CFLAGS" if available. This seems like it would do "the right thing" more often without user intervention and is safe when getconf is not available. If LARGEFILE were set in the environment (by a command line such as you suggest), we'd just use that instead. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

Barry A. Warsaw writes:

+1

BTW, does anybody have a manpage for getconf?

Not for Linux, but you aleady have the command line we care about. I've attached a Solaris manpage. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation User Commands getconf(1) NAME getconf - get configuration values SYNOPSIS getconf [ -v _s_p_e_c_i_f_i_c_a_t_i_o_n ] _s_y_s_t_e_m__v_a_r getconf [ -v _s_p_e_c_i_f_i_c_a_t_i_o_n ] _p_a_t_h__v_a_r _p_a_t_h_n_a_m_e getconf -a DESCRIPTION In the first synopsis form, the getconf utility will write to the standard output the value of the variable specified by _s_y_s_t_e_m__v_a_r, in accordance with _s_p_e_c_i_f_i_c_a_t_i_o_n if the -v option is used. In the second synopsis form, getconf will write to the stan- dard output the value of the variable specified by _p_a_t_h__v_a_r for the path specified by _p_a_t_h_n_a_m_e, in accordance with _s_p_e_c_i_f_i_c_a_t_i_o_n if the -v option is used. In the third synopsis form, config will write to the stan- dard output the names of the current system configuration variables. The value of each configuration variable will be determined as if it were obtained by calling the function from which it is defined to be available. The value will reflect condi- tions in the current operating environment. OPTIONS The following options are supported: -a Writes the names of the current system configuration variables to the standard output. -v _s_p_e_c_i_f_i_c_a_t_i_o_n Gives the specification which governs the selection of values for configuration variables. OPERANDS The following operands are supported: _p_a_t_h__v_a_r A name of a configuration variable whose value is available from the pathconf(2) function. All of the values in the following table are supported: LINK_MAX _N_A_M_E__M_A_X POSIX_CHOWN_RESTRICTED MAX_CANON _P_A_T_H__M_A_X POSIX_NO_TRUNC MAX_INPUT PIPE_BUF POSIX_VDISABLE SunOS 5.8 Last change: 30 Jan 1998 1 User Commands getconf(1) _p_a_t_h_n_a_m_e A path name for which the variable specified by _p_a_t_h__v_a_r is to be determined. _s_y_s_t_e_m__v_a_r A name of a configuration variable whose value is available from confstr(3C) or sysconf(3C). All of the values in the following table are supported: ARG_MAX _B_C__B_A_S_E__M_A_X BC_DIM_MAX _B_C__S_C_A_L_E__M_A_X BC_STRING_MAX CHAR_BIT CHARCLASS_NAME_MAX CHAR_MAX CHAR_MIN CHILD_MAX CLK_TCK COLL_WEIGHTS_MAX CS_PATH EXPR_NEST_MAX INT_MAX INT_MIN LFS64_CFLAGS LFS64_LDFLAGS LFS64_LIBS LFS64_LINTFLAGS LFS_CFLAGS LFS_LDFLAGS LFS_LIBS LFS_LINTFLAGS LINE_MAX LONG_BIT LONG_MAX LONG_MIN MB_LEN_MAX NGROUPS_MAX NL_ARGMAX NL_LANGMAX NL_MSGMAX NL_NMAX NL_SETMAX NL_TEXTMAX NZERO OPEN_MAX POSIX2_BC_BASE_MAX POSIX2_BC_DIM_MAX POSIX2_BC_SCALE_MAX POSIX2_BC_STRING_MAX POSIX2_C_BIND POSIX2_C_DEV POSIX2_CHAR_TERM POSIX2_COLL_WEIGHTS_MAX POSIX2_C_VERSION POSIX2_EXPR_NEST_MAX POSIX2_FORT_DEV POSIX2_FORT_RUN POSIX2_LINE_MAX POSIX2_LOCALEDEF POSIX2_RE_DUP_MAX POSIX2_SW_DEV POSIX2_UPE POSIX2_VERSION _POSIX_ARG_MAX _POSIX_CHILD_MAX _POSIX_JOB_CONTROL _POSIX_LINK_MAX _POSIX_MAX_CANON _POSIX_MAX_INPUT _POSIX_NAME_MAX _POSIX_NGROUPS_MAX _POSIX_OPEN_MAX _POSIX_PATH_MAX _POSIX_PIPE_BUF _POSIX_SAVED_IDS _POSIX_SSIZE_MAX _POSIX_STREAM_MAX _POSIX_TZNAME_MAX _POSIX_VERSION RE_DUP_MAX SCHAR_MAX SCHAR_MIN SHRT_MAX SHRT_MIN SSIZE_MAX STREAM_MAX TMP_MAX TZNAME_MAX UCHAR_MAX UINT_MAX ULONG_MAX USHRT_MAX WORD_BIT SunOS 5.8 Last change: 30 Jan 1998 2 User Commands getconf(1) XBS5_ILP32_OFF32 XBS5_ILP32_OFF32_CFLAGS XBS5_ILP32_OFF32_LDFLAGS XBS5_ILP32_OFF32_LIBS XBS5_ILP32_OFF32_LINTFLAGS XBS5_ILP32_OFFBIG XBS5_ILP32_OFFBIG_CFLAGS XBS5_ILP32_OFFBIG_LDFLAGS XBS5_ILP32_OFFBIG_LIBS XBS5_ILP32_OFFBIG_LINTFLAGS XBS5_LP64_OFF64 XBS5_LP64_OFF64_CFLAGS XBS5_LP64_OFF64_LDFLAGS XBS5_LP64_OFF64_LIBS XBS5_LP64_OFF64_LINTFLAGS XBS5_LPBIG_OFFBIG XBS5_LPBIG_OFFBIG_CFLAGS XBS5_LPBIG_OFFBIG_LDFLAGS XBS5_LPBIG_OFFBIG_LIBS XBS5_LPBIG_OFFBIG_LINTFLAGS _XOPEN_CRYPT _XOPEN_ENH_I18N _XOPEN_LEGACY _XOPEN_SHM _XOPEN_VERSION _XOPEN_XCU_VERSION _XOPEN_XPG2 _XOPEN_XPG3 _XOPEN_XPG4 The symbol PATH also is recognized, yielding the same value as the confstr() name value CS_PATH. USAGE See largefile(5) for the description of the behavior of getconf when encountering files greater than or equal to 2 Gbyte ( 2**31 bytes). EXAMPLES Example 1: Writing the value of a variable This example illustrates the value of {NGROUPS_MAX}: example% getconf NGROUPS_MAX Example 2: Writing the value of a variable for a specific directory This example illustrates the value of NAME_MAX for a specific directory: example% getconf NAME_MAX /usr Example 3: Dealing with unspecified results This example shows how to deal more carefully with results that might be unspecified: if value=$(getconf PATH_MAX /usr); then if [ "$value" = "undefined" ]; then echo PATH_MAX in /usr is infinite. else echo PATH_MAX in /usr is $value. fi else SunOS 5.8 Last change: 30 Jan 1998 3 User Commands getconf(1) echo Error in getconf. fi Note that sysconf(_SC_POSIX_C_BIND); and system("getconf POSIX2_C_BIND"); in a C program could give different answers. The sysconf call supplies a value that corresponds to the conditions when the program was either compiled or executed, depending on the implementation; the system call to getconf always supplies a value corresponding to conditions when the pro- gram is executed. ENVIRONMENT VARIABLES See environ(5) for descriptions of the following environment variables that affect the execution of getconf: LC_CTYPE, LC_MESSAGES, and NLSPATH. EXIT STATUS The following exit values are returned: 0 The specified variable is valid and information about its current state was written successfully. >0 An error occurred. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |______________________________|______________________________| | Availability | SUNWcsu | |______________________________|______________________________| SEE ALSO pathconf(2), confstr(3C), sysconf(3C), attributes(5), environ(5), largefile(5) SunOS 5.8 Last change: 30 Jan 1998 4

(trimming the cc list... i think everyone on it is a p-dev'er) Martin> Anyway, what is wrong with my earlier suggestion Martin> export CFLAGS OPT Martin> CFLAGS='-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64' Martin> OPT="-g -O2 $CFLAGS" Martin> ./configure I know I'm coming into this discussion late, but why even involve CFLAGS? export OPT OPT='-g -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64' ./configure Skip

...

...

...

...

"MvL" == Martin v Loewis writes:

MvL> "is used to create the compilation command" may be tricky to MvL> implement. Anyway, what is wrong with my earlier suggestion | export CFLAGS OPT | CFLAGS='-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64' | OPT="-g -O2 $CFLAGS" | ./configure Two problems: 1) This requires you to export two variables into the outer shell's environment. As a general rule, I think this is a bad idea for tricking configure. What else might you be affecting? Others might not care as much. 2) Any time you overload a make variable that has existing semantics, you have to worry about losing the original value. Personally, I think it's easier to get CC overloading right than get OPT or CFLAGS overloading (and easier than getting them both right). But maybe that's just me. -Barry

...

...

...

...

"AM" == Aahz Maruch writes:

AM> OTOH, if MvL's code is in a shell script, this objection AM> doesn't apply. I must have missed that. Was Martin suggesting a shell script, like "configure-lfs"? -Barry

Barry A. Warsaw wrote:

...

...

...

...

...

"AM" == Aahz Maruch writes:

AM> OTOH, if MvL's code is in a shell script, this objection AM> doesn't apply.

I must have missed that. Was Martin suggesting a shell script, like "configure-lfs"?

Martin didn't, but it answers your objection. ;-) -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista We must not let the evil of a few trample the freedoms of the many.

AM> OTOH, if MvL's code is in a shell script, this objection AM> doesn't apply.

I must have missed that. Was Martin suggesting a shell script, like "configure-lfs"?

No, I was really talking about the instructions in the manual, which would then indeed result in OPT being in the environment after configure has completed. If that is considered unacceptable, I'm fine with documenting that CC should be set in the environment - even though such instruction may also break on some systems. Enhancing configure to take into account more environment variables is worse: the risk of introducing new errors is just too high. Regards, Martin

...

...

...

...

"MvL" == Martin v Loewis writes:

>> 2) Any time you overload a make variable that has existing >> semantics, you have to worry about losing the original value. >> Personally, I think it's easier to get CC overloading right >> than get OPT or CFLAGS overloading (and easier than getting >> them both right). But maybe that's just me. MvL> Ok. For Solaris and Linux, the instruction about setting CC MvL> is about right, so I'm no longer objecting to changing the MvL> documentation in that direction. It is just that if you MvL> specify --without-gcc, or are on SGI or BSD/OS, that your MvL> environment setting of CC will be ignored. Good point. This should definitely be mentioned in the docs. then-again-future-google-searches-are-sure-to-turn-up-this-entire-painful -thread-ly y'rs, -Barry

I think the intent was to use single quotes for OPT='two $CFLAGS'. (You could also do OPT="two \$CFLAGS".) This will pass the string "$CFLAGS" in OPT, not the value of the shell variable $CFLAGS.

While your shell script will print out: OPT = xtwo $CFLAGSx This is ok since it will/should get expanded properly in the Makefile.

Or I've totally missed the point too. :-)

The intent really was that the later assigment takes into account the earlier one, by means of shell expansion. Setting OPT to a value that depends on CFLAGS would give you a cyclic expansion in the Makefile - so that clearly was not the intent. You need to set both because one ends up in the Makefile (OPT) whereas the other (CFLAGS) is needed to convince configure that HAVE_LARGEFILE should be turned on. Regards, Martin

MvL> I think the best approach is to copy the body of MvL> _portable_fseek and _portable_ftell from 2.2. With that, I MvL> get a setup that atleast looks right (patch attached)

Unfortunately that's not enough, I suspect.

I can't see a problem.

Vanilla release21-maint will give compilation failures, which go away with the patch (essentially what I tried on other systems). But even with these patches, test_largefile fails on the seek(2**31L).

Not for me (i.e. it passes just fine). How exactly does it fail? What version of the test? Can you produce an strace?

FTR: this is a stock Mandrake 8.1 system w/ glibc 2.2.4.

That should be good enough.

I don't have much time to spend looking into this right now, but it would be good to fix for 2.1.2.

Somebody else should probably try this as well. I would not stop the release for that: if it compiles fine when following the instructions, and does the right thing for small files, I think the release should go. Regards, Martin

[Guido]

I'm guessing you'll also need Fred's help to roll out the docs (are there going to be 2.1.2 docs?) and Tim's for the windows installer (which may be a bit of a pain since we've switched installer builders for 2.2).

Ouch. More than a bit -- I'd have to find the old Wise floppy first (it's not on my disk anymore). But the 16-bit installer is itself "a bug" (often doesn't work) on the recent MS high-end OSes (2000 and XP), so creating another of those is a dubious exercise. We were probably shipping different versions of expat and/or zlib on Windows for 2.1 too (but at least I can suck those binaries out of an installed 2.1 -- or was Windows 2.1 compiled with a binary-incompatible MSVC 5?). Etc. If I do this, it's going to consume at least a day to straighten out all the issues.

[Guido]

2.1 was solidly MSVC 6, so I don't think there were any MSVC 5 issues.

That matches my recollection, but while I'd bet your life on it I wouldn't bet mine <wink>.

Would it be a problem if we used the new installer for 2.1.2? That would be much easier on Tim.

The real reason to use the new installer is that the old one is, and increasingly as 2000 and XP get more popular, itself "a bug". Getting a 32-bit installer is increasingly necessary, and the old installer can't deal with the Win2K privilege maze at all (usually spelling "insufficient privilege" as "corrupt installation detected" before its first dialog box even appears -- the old Wise 16-bit-installer builder was released when Win95 was brand new).

There are still some issues (e.g. expat) but I'm not qualified to rule on those.

I'll ask Fred about that one offline. It's all doable, it's just going to consume some time.

[Martin v. Loewis]

My guess is that 2.1.2 will compile fine with whatever expat installation Tim currently has, if it does, pyexpat will certainly work correctly (or: as good as it did in 2.1.1).

It changes the structure of the distribution, though: 2.1 Windows Python shipped with xmlparse.dll and xmltok.dll, 2.2 with neither of those but with a single expat.dll instead. Regardless of whether "it works" for Python, I don't think a bugfix release is the time to change the *set* of DLLs we ship. The MSVC project files on the 2.1 branch also have no idea what to do with the current expat setup, and last-second changes just multiply if I fight that too (the 2.1 PCbuild README would also need to be changed; etc). 2.2 is better here, but the old expat setup wasn't "a bug"; people who want the new setup should upgrade to 2.2, where it was first introduced.

On that topic, is there anybody else in this list who has the necessary software to build a Python Windows release? I feel quite uncomfortable thinking that, if your PC crashes, Windows people would be without Python (actually, *that* uncomfortable is that thought not :-)

I have the whole suite working on my laptop too.

This would probably the time to step forward offering to build the official 2.1.2 binary distribution.

But I'm not volunteering. --Guido van Rossum (home page: http://www.python.org/~guido/)

Tim Peters wrote:

[Guido]

...

I have the whole suite working on my laptop too.

I wasn't going to admit that: that one's a serious license violation <wink>.

Is it really ? Most desktop apps nowadays allow one additional laptop installation. Totally off-topic, of course, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

[Martin v. Loewis]

Right, I agree on all accounts. Do whatever is most convenient for you.

I don't care what's convenient, I want to do what's *right* for 2.1.2. I think this got confused because Guido sold "use the new installer-builder" on the grounds that it would be easier for me, but, while that's true, it's also true that the old installer-builder produces broken installers (useless for many Win2K/XP users). The latter is the real reason I want to use the new installer-builder; the old one is quite arguably "a bug".

On that topic, is there anybody else in this list who has the necessary software to build a Python Windows release? I feel quite uncomfortable thinking that, if your PC crashes, Windows people would be without Python (actually, *that* uncomfortable is that thought not :-)

The only pieces you can't get for free over the Web are MSVC 6 and Wise 8.14; the MSVC and Wise project files are in CVS, so it's only the MS and Wise executables someone would have to obtain. PythonLabs has the physical CDs for those, so it doesn't matter much if my box crashes; I also have at least 3 copies of them on backup tapes, and two other copies on two other machines. Hmm. I probably violated the license agreements at least 4 times there .

This would probably the time to step forward offering to build the official 2.1.2 binary distribution.

Don't I wish. I would like to see us move to a free installer. I built (and checked in) an Inno Setup project file that does "almost all" the good stuff, and advertised on c.l.py for volunteers to take it over. Alas, nobody bit, and I can't justify spending more of my time on it (I could at the time because I wasn't making any progress then getting Wise to let us use a new version of their stuff, and Inno Setup was the only feasible alternative).