[Python-bugs-list] [ python-Bugs-417491 ] UnixWare BUILD *STILL* uses ld -G

[noreply@sourceforge.net]

Bugs item #417491, was updated on 2001-04-19 16:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Rosenman (ler)
Assigned to: Nobody/Anonymous (nobody)
Summary: UnixWare BUILD *STILL* uses ld -G

Initial Comment:
bug 231439 is BACK in the 2.1 final release.  It still
uses ld -G. 

ALL shared objects, ESPECIALLY those using threads,
should be compiled  *AND* linked using cc -G. 

I'm very disappointed in that the bug was closed but
the QA process dropped the fix(es). 


ALSO, when doing the initial build using Shared
Objects, you need to set -R and/or set LD_LIBRARY_PATH
to suit. 



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

>Comment By: Tim Peters (tim_one)
Date: 2001-04-21 19:30

Message:
Logged In: YES 
user_id=31435

LARRY, there's REALLY no need to SCREAM on *EACH* word in 
THREE <wink>.

You're not impressed by QA -- join the club.  Testing is 
done by volunteers, and if there are no volunteers *trying* 
the release candidates on a new platform, we have no way to 
know whether they work.  Linux and Windows and Mac Classic 
are pretty well covered by volunteers, but that's about 
it.  If UnixWare is important enough to you, volunteer to 
test release candidates there yourself, or even pay someone 
to do it.  But don't go honking on Martin!  That's out of 
line.

About your "The last comments on this patch are telling.", 
the last comments on that patch were made *after* the 
release.  Before the release, Guido checked in the patch 
that the UnixWare user said was needed.  He can't guess 
whether a patch actually works on a platform he doesn't 
use.  The last patch comment by a UnixWare user *before* 
the release reads

"""Every thing looks fine (as far as I can tell)."""

WRT "why the H*LL didn't the release .tar get RE-ROLLED?", 
it's because nobody said anything was broken until after 
the release shipped (your bug report here was 2 days after 
the release).

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

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 17:34

Message:
Logged In: YES 
user_id=36452

OK, here is a patch I wrote to configure.in to fix this. 
regen configure and config.h.in 

Let me know if this is acceptable.  THis is against the
2.1-RELEASE version. 

Larry 

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

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:45

Message:
Logged In: YES 
user_id=36452

Oh, and 1.215 is *BROKE*, as it spec's ld -G, not CC -G,
around line 615 or so.

PLEASE fix. 

PLEASE generate a FIX RELEASE for the 2.1 RELEASE.

This is *NOT* a good sign that a broken PORT didn't stop the
release process. 



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

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:23

Message:
Logged In: YES 
user_id=36452

OK, why the H*LL didn't the release .tar get RE-ROLLED?  The
last comments on this patch are telling.  

I'm *NOT* impressed, and the bug reported here is mentioned
in that stream, so why wasn't the RELEASE held for this? 
the port is PROMINENTLY mentioned in the release notes, but
it's BROKE in the RELEASE.  How can I get a new tarball from
y'all? 



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

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-21 05:55

Message:
Logged In: YES 
user_id=21627

I agree this is very unfortunate. Please have a look at
patch 413011, which was committed as 1.215 of configure.in.

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

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