--- Configure.pl (revision 16268)
+++ Configure.pl (revision 16416)
@@ -464,9 +464,9 @@
> What is your c++ symlink pointing at?
[parrot] 512 $ ls -l /usr/bin/c++
lrwxr-xr-x 1 root wheel 7 Aug 9 2004 /usr/bin/c++ -> g++-3.3
[parrot] 513 $ ls -l /usr/bin/g++-3.3
-r-xr-xr-x 1 root wheel 135816 May 14 2006 /usr/bin/g++-3.3
OK, this problem must be something similar to the linking problems I
have with suncc on Linux. Even though I specify everything on the
Configure.pl command-line in terms of --cc and --link, it magically
switches to g++ when trying to link. Obviously, then, the hints or
something that runs after is misbehaving and redefining variables
> On Sun Jan 07 08:27:28 2007, jk...@verizon.net wrote:
> OK, this problem must be something similar to the linking problems I
> have with suncc on Linux. Even though I specify everything on the
> Configure.pl command-line in terms of --cc and --link, it magically
> switches to g++ when trying to link. Obviously, then, the hints or
> something that runs after is misbehaving and redefining variables
> configuration variables.
As noted previously, once I reverted to the previous order of running
the steps, I had no problem. I've successfully run 'make' quite a
few times since then.
I'm still not seeing the effects of the bug you describe, btw. (on OS X
intel or ppc). It does remind me of issues I had when attempting to use
the GMP libs, though.
> > ...I inferred that some change in the configuration process in the
> > days had caused Configure.pl to override my environmental setting of
> > 'ld' to '/usr/bin/g++-3.3'.
> > Running an 'svn diff' on the last two versions of Configure.pl (see
> > attached recent.changes.Configure.pl.txt), I saw:
> > Index: Configure.pl
> > ==========================================
> > --- Configure.pl (revision 16268)
> > +++ Configure.pl (revision 16416)
> > @@ -464,9 +464,9 @@
> > init::defaults
> > init::install
> > init::miniparrot
> > + inter::progs
> > init::hints
> > init::headers
> > - inter::progs
> > inter::make
> > inter::lex
> > inter::yacc
> > ... indicating that step 'inter::progs' is to be performed
> > immediately before 'init::hints', rather than two steps afterwards.
> > I peered into config/inter/progs.pm (for the very first time) and
> > noted that it has a provision for setting the value of 'ld'. config/
> > inter/progs.pm itself had not been changed in the last 3 days,
> > therefore I hypothesized that my problems were *solely* to the patch
> > applied to Configure.pl on Jan 04.
> > Once I ran 'make realclean' and 'svn update', I then manually
> > reverted Configure.pl to have 'inter::progs' done two steps after
> > 'init::hints'. I then examined the resulting 'myconfig' and saw that,
> as I desired, line 12 once again ran:
> > ld='/usr/bin/g++-3.3'
> > I then ran 'make', which DWIMmed. ...
> > On the basis of the above, I recommend that Configure.pl be reverted
> > to r16268. (If that cannot be done, then I would like to know how to
> > call Configure.pl so that I can 'make' Parrot successfully.)
> The bug has not been addressed. Up until the last few days, I was
> content to let it go. But now I'm worried that it may be the cause of
> the bug t/pmc/object-mro.t I reported this morning
Do you still get the bug when you revert the change to Configure.pl?
I tried reverting the change in a local copy of svn head today: seems to
work the same for me either way, so unless another platform objects,
let's switch it back if it fixes things for you.
> On Mon Mar 05 16:57:47 2007, jk...@verizon.net wrote:
>> Two months ago, I filed this bug report (excerpt):
> I'm still not seeing the effects of the bug you describe, btw. (on
> OS X
> intel or ppc). It does remind me of issues I had when attempting to
> the GMP libs, though.
Was out all day; I'll look into it this weekend. Thanks for checking
up on it.
> Do you still get the bug when you revert the change to Configure.pl?
This morning, I checked out a fresh version from trunk: r17419. I
ran myconfigure.sh, which internally called the HEAD version of
/usr/local/bin/perl Configure.pl --cc="$CC" --cxx="$CX" --
link="$CX" --ld="$CX" --without-icu --without-gmp $@
The configuration built thereby is attached in 'myconfig.first.txt'.
I then ran 'make'. 'make' failed; here's the output starting at line
make: Leaving directory `/Users/jimk/work/fresh/docs'
c++ -bundle -undefined suppress -L/usr/local/lib -L/Users/jimk/
work/fresh/blib/lib -flat_namespace \
-o runtime/parrot/dynext/libnci_test.bundle src/nci_test.o -lm
c++: couldn't run 'undle-gcc-4.0.3': No such file or directory
<-- line 605
make: *** [runtime/parrot/dynext/libnci_test.bundle] Error 1
Note the 'undle-gcc-4.0.3' in line 605. This misspelling is a
different instance of the same problem that we addressed with
I then reverted to the previous version of Configure.pl, which I
attach as 'my_Configure.pl'. I called 'make realclean',
'myconfigure.sh'. The resulting configuration created is attached as
'myconfig.second.txt', but here's the diff between the two myconfig's:
[fresh] 514 $ diff myconfig.first.txt myconfig.second.txt
< configdate='Sat Mar 10 09:40:26 2007'
> configdate='Sat Mar 10 10:05:47 2007'
< ld='c++', ldflags=' -L/usr/local/lib -L/Users/jimk/work/fresh/
blib/lib -flat_namespace ',
> ld='/usr/bin/g++-3.3', ldflags=' -L/usr/local/lib -L/Users/
jimk/work/fresh/blib/lib -flat_namespace ',
< libs=' -lm'
I then re-ran 'make'. 'make' succeeded. All of the above -- problem
and (hack) solution -- is consistent with all my results over the
last two months since I originally reported the problem.
I should note that I can do a "straight-out-of-the-HEAD-box"
compilation on Linux with no additional configuration options,
On Fri Mar 16 19:24:55 2007, jk...@verizon.net wrote:
> Results confirmed again at r17522 tonight.