Hearing no objections, am resolving ticket.
The dénouement.
I spoke with Allison in the course of #parrotsketch yesterday and
subsequently off-line. She recommended that I upgrade to Xcode 2.5
Developer Tools
(https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=19907).
The 2.5 version, among other things, i
On Thu Mar 20 16:59:55 2008, [EMAIL PROTECTED] wrote:
> The dynamic lookup patch was applied in the PDD 17 branch, and merged in
> with the rest of the branch. As I understood it, your problem with the
> patch was that you didn't have MACOSX_DEPLOYMENT_TARGET properly set to
> 10.3, and I remem
James Keenan via RT wrote:
This thread petered out after January 30, which was fine with me because
we couldn't diagnose why Allison's proposed patch was causing
Configure.pl to throw warnings on Darwin (OS X 10.4.11, ppc, gcc-3.3) at
config/auto/readline.pm. Configure.pl quietly did its thing f
Not surprisingly (given discussion earlier in this thread), reverting
the part of r26309 pertaining to config/init/hints/darwin.pm resolved
this problem, quieting config/auto/readline.pm during configuration.
Determining if your platform supports readline..no.
See patch at
And the loser is: r26309:
Determining if your platform supports readline...dyld: lazy symbol
binding failed: Symbol not found: _rl_get_keymap
Referenced from: /Users/jimk/work/26309/./test
Expected in: dynamic lookup
dyld: Symbol not found: _rl_get_keymap
Referenced from: /Users/jimk/work/
Narrowing it down, I see that the damage occurred after r26306. (But I
was wrong in my earlier statement that Configure.pl was previously
detecting readline on my iBook; it was not.)
Determining if your platform supports readline..no.
Determining if your platform supports
On Thu Mar 13 19:24:57 2008, [EMAIL PROTECTED] wrote:
>
>
> Could we find out who committed what, when and why, so that we can
> discuss remedies?
>
Note: To rule out the obvious suspect, this problem was *not* caused by
ambs's patch on Wed Mar 12 to config/auto/readline.pm. It occurred
then,
This thread petered out after January 30, which was fine with me because
we couldn't diagnose why Allison's proposed patch was causing
Configure.pl to throw warnings on Darwin (OS X 10.4.11, ppc, gcc-3.3) at
config/auto/readline.pm. Configure.pl quietly did its thing for me for
the next 6 weeks.
On Wed Jan 30 18:36:27 2008, [EMAIL PROTECTED] wrote:
>
> Try manually adding -lreadline to the test compile in auto::readline and
> see what happens.
>
This is what I did:
Index: config/auto/readline.pm
===
--- config/auto/readl
James Keenan via RT wrote:
On Tue Jan 29 19:42:15 2008, [EMAIL PROTECTED] wrote:
Does C_LIBS have -lreadline included?
No, it does not.
C_LIBS = -lm -lgmp
Which is not surprising. If you recall, the result set by
auto::readline in the spewing case was 'no'. So with your patch
readlin
On Tue Jan 29 19:42:15 2008, [EMAIL PROTECTED] wrote:
>
> Does C_LIBS have -lreadline included?
>
> Allison
>
Here's how 'libs' evolves over the course of configuration on my ibook.
Tracing evolution of libs ...
init::manifest =>
init::defaults => -lgdbm -ldbm -ldl -lm -lc
init::install =
On Tue Jan 29 19:42:15 2008, [EMAIL PROTECTED] wrote:
>
> Does C_LIBS have -lreadline included?
>
No, it does not.
C_LIBS = -lm -lgmp
Which is not surprising. If you recall, the result set by
auto::readline in the spewing case was 'no'. So with your patch
readline is not being found.
(B
James Keenan via RT wrote:
[...]
However, the spewing problem occured at auto::readline -- one step
*before* the first superfluous addition of a flag.
Okay, so (summarizing) at the point of running auto::readline, -L/sw/lib
and -I/sw/include are all set appropriately.
Does C_LIBS have -lread
I just sent off a patch for the duplicate flags problem; it will appear
in a separate RT and I'll commit it to trunk in a day if there is no
objection.
However, it did *not* fix the spewing problem with auto::readline.
Here's my latest configuration log. This was run with both Allison's
patch t
I see that I misread your post; 'ldflags' should have included
-L/sw/lib, and it does. Here's the evolution of 'ccflags' in the same
region:
{
'auto::aio' => '-fno-common -no-cpp-precomp -pipe
-I/usr/local/include -pipe -fno-common -Wno-long-double
-DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRE
On Tue Jan 29 16:40:22 2008, [EMAIL PROTECTED] wrote:
>
> The spewing in auto::readline is caused by it failing to detect readline
> from Fink.
>
> In the generated Makefile, both LINKFLAGS and LDFLAGS should include the
> entry "-L/sw/lib" and CFLAGS should include the entry "-I/sw/include".
James Keenan via RT wrote:
Note the spewing during auto::readline; never had that before. Note
further that this failed to detect that I have readline installed via
Fink. Whazzup with that?
The spewing in auto::readline is caused by it failing to detect readline
from Fink.
In the generate
James Keenan via RT wrote:
Nope.
[parrot] 521 $ ./myconfigure.sh
MACOSX_DEPLOYMENT TARGET is 10.3
There seems to be a missing underscore in "MACOSX_DEPLOYMENT TARGET",
but that's probably just your debug message.
Did you try 'export'? Configure spawns its own processes which may be
resett
On Mon, 28 Jan 2008, James Keenan via RT wrote:
> Here's the verbose output on the failing configuration step, inter::progs.
>
> First, with my usual settings:
>
> Determining what C compiler and linker to use...
> ccflags: -fno-common -no-cpp-precomp -pipe -I/usr/local/include -pipe
> -fno-co
Nope.
[parrot] 521 $ ./myconfigure.sh
MACOSX_DEPLOYMENT TARGET is 10.3
Parrot Version 0.5.2 Configure 2.0
Copyright (C) 2001-2008, The Perl Foundation.
Hello, I'm Configure. My job is to poke and prod your system to figure out
how to build Parrot. The process is completely automated, unless you
Here's the verbose output on the failing configuration step, inter::progs.
First, with my usual settings:
Determining what C compiler and linker to use...
ccflags: -fno-common -no-cpp-precomp -pipe -I/usr/local/include -pipe
-fno-common -Wno-long-double
/usr/bin/gcc-3.3 -fno-common -no-cpp-pre
James Keenan via RT wrote:
I first tried setting the environmental variable, then using my startup
script in test mode:
$ echo $MACOSX_DEPLOYMENT_TARGET
10.3
#!/bin/sh
CC="/usr/bin/gcc-3.3"
CX="/usr/bin/g++-3.3"
/usr/local/bin/perl Configure.pl --cc="$CC" --cxx="$CX" --link="$CX" \
--ld="$
On Mon Jan 28 00:30:51 2008, [EMAIL PROTECTED] wrote:
> James Keenan via RT wrote:
> >>
> > Okay, I figured out how to do that ... but no better results.
> >
> > [parrot] 566 $ MACOSX_DEPLOYMENT_TARGET=10.4
> [...]
> >
> > Setting the environmental variable apparently didn't stick.
>
> I can dup
On 28/01/2008, James Keenan via RT <[EMAIL PROTECTED]> wrote:
> On Sun Jan 27 17:14:11 2008, tiro wrote:
>
> >
> > Could you try setting MACOSX_DEPLOYMENT_TARGET to 10.4 to see if that
> > fixes the problem?
> >
> Okay, I figured out how to do that ... but no better results.
>
> [parrot] 566 $ MACO
James Keenan via RT wrote:
Okay, I figured out how to do that ... but no better results.
[parrot] 566 $ MACOSX_DEPLOYMENT_TARGET=10.4
[...]
Setting the environmental variable apparently didn't stick.
I can duplicate the failure when I use your startup script. First, try
setting the envir
James Keenan via RT wrote:
Determining what C compiler and linker to use...
ccflags: -fno-common -no-cpp-precomp -pipe -I/usr/local/include -pipe
-fno-common -Wno-long-double
/usr/bin/gcc-3.3 -fno-common -no-cpp-precomp -pipe -I/usr/local/include
-pipe -fno-common -Wno-long-double -I./inc
On Sun Jan 27 17:14:11 2008, tiro wrote:
>
> Could you try setting MACOSX_DEPLOYMENT_TARGET to 10.4 to see if that
> fixes the problem?
>
Okay, I figured out how to do that ... but no better results.
[parrot] 566 $ MACOSX_DEPLOYMENT_TARGET=10.4
[parrot] 567 $ echo $MACOSX_DEPLOYMENT_TARGET
10.4
On Sun Jan 27 17:14:11 2008, tiro wrote:
>
> Could you try setting MACOSX_DEPLOYMENT_TARGET to 10.4 to see if that
> fixes the problem?
>
How/where do I do that?
James Keenan via RT wrote on Sun, Jan 27, 2008 at 04:32:59PM PST:
> ...
> Determining what C compiler and linker to use...Compilation failed with
> '/usr/bin/gcc-3.3'
>
> Here's the output with -verbose-step=7 (inter::progs).
>
> Determining what C compiler and linker to use...
> ccflags: -fno-c
I began by running configuration with tests. Specifically:
#!/bin/sh
CC="/usr/bin/gcc-3.3"
CX="/usr/bin/g++-3.3"
/usr/local/bin/perl Configure.pl --cc="$CC" --cxx="$CX" --link="$CX" \
--ld="$CX" --without-icu --without-gmp \
--test \
--configure_trace \
$@
... which is the way I
On Sun Jan 27 09:19:32 2008, [EMAIL PROTECTED] wrote:
>
> Allison: I have 3 different patches from you in this thread in the last
> day. Which one or which combination do you most want tried out?
Test the most recent one, darwin_full_dynamic_symbol_lookup.patch.
> (moi: ppc-darwin 10.4.11)
Allison Randal via RT wrote:
If you're running some flavor of OS X, please test this patch.
Allison: I have 3 different patches from you in this thread in the last
day. Which one or which combination do you most want tried out?
(moi: ppc-darwin 10.4.11)
On Sun, 27 Jan 2008, Allison Randal wrote:
> Andy Dougherty via RT wrote:
> > I'd say rip it out and let someone who understands all the darwin-specific
> > behavior well worry about putting it in, *commenting it in the hints
> > file*, and maintaining it.
>
> Going back to a static build was th
The attached patch removes '-flat_namespace' and consistently uses
'-undefined dynamic_lookup'. It also restricts the changes to just the
darwin config hints file, which seems like a more appropriate place. It
resolves all the test failures related to undefined symbols on OS X.
(t/src/intlist.t is
Andy Dougherty via RT wrote:
+
+unless osname == 'darwin' goto not_darwin
+ link .= '-undefined dynamic_lookup '
+not_darwin:
+
I understand and sympathize with wanting to just get past this problem,
but this looks to me like layering more magic to undo the bad magic
applied ea
On Sat, 26 Jan 2008, Allison Randal via RT wrote:
> The attached patch allows 'make' to complete on my OS X box, and passes
> 'make test'.
> --- tools/dev/pbc_to_exe_gen.pl (revision 25264)
> +++ tools/dev/pbc_to_exe_gen.pl (working copy)
> @@ -351,6 +351,11 @@
> .local string li
On Saturday 26 January 2008 19:01:48 Allison Randal via RT wrote:
> But, I won't commit the patch until I have some confirmation on whether
> the segfault happens without the patch on other platforms, or with the
> patch on other darwin-based installs. At least I can apply the patch to
> my workin
The attached patch allows 'make' to complete on my OS X box, and passes
'make test'. It gets a segfault when running 'make perl6', at the point
where it runs 'pbc_to_exe perl6.pbc'. The segfault appears to be a
standard GC-style error attempting to access reclaimed memory, and not
related to symbol
Update:
Nat Torkington wrote a test case for the features we're using (compiling
a dynamic library, and compiling an executable that uses that library),
which I've attached. The test case works, and is fundamentally the same
as what Parrot is doing. I've been stepping through the differences
betwe
On Wed, 23 Jan 2008, chromatic wrote:
> On Wednesday 23 January 2008 10:20:03 Andy Dougherty wrote:
>
> > my suggested reordering is unlikely to fix this. ?The undefined
> > symbol '_Parrot_set_executable_name' is referenced in pbc_to_exe.o, so
> > the linker should have been looking for it alrea
On Wednesday 23 January 2008 10:20:03 Andy Dougherty wrote:
> my suggested reordering is unlikely to fix this. The undefined
> symbol '_Parrot_set_executable_name' is referenced in pbc_to_exe.o, so
> the linker should have been looking for it already when it encountered
> -lparrot. This indeed l
On Wed, 23 Jan 2008, Andy Dougherty wrote:
> On Wed, 23 Jan 2008, Allison Randal via RT wrote:
>
> Summary (edited for clarity)
>
> > > c++ -o pbc_to_exe pbc_to_exe.o -Lblib/lib -lparrot src/parrot_config.o
>
> Fails. But adding $O_FILES to the end works:
>
> >> c++ -o pbc_to_exe pbc_to_exe.o
On Wed, 23 Jan 2008, Allison Randal via RT wrote:
Summary (edited for clarity)
> > c++ -o pbc_to_exe pbc_to_exe.o -Lblib/lib -lparrot src/parrot_config.o
Fails. But adding $O_FILES to the end works:
>> c++ -o pbc_to_exe pbc_to_exe.o -Lblib/lib -lparrot src/parrot_config.o
>> $(O_FILES)
This
It also works as a shared binary if I append the following to the
compile line (pretty much exactly the contents of $O_FILES in the Makefile):
c++ -o pbc_to_exe pbc_to_exe.o -L/usr/local/lib -L/opt/local/lib
-L/sw/lib -L/sw/lib -L/opt/local/lib -L/sw/lib
-L/Users/allison/projects/svn/parrot/blib/
On 23/01/2008, Allison Randal via RT <[EMAIL PROTECTED]> wrote:
> On Tue Jan 22 15:38:11 2008, [EMAIL PROTECTED] wrote:
> >
> > Are you building a static or a shared binary? Did this problem only
> > show up after Coke switched the default to shared?
>
> Shared. I don't know the exact timing of th
On Tue Jan 22 15:38:11 2008, [EMAIL PROTECTED] wrote:
>
> Are you building a static or a shared binary? Did this problem only
> show up after Coke switched the default to shared?
Shared. I don't know the exact timing of the change in relation to the
failure starting. But, changing config/init/hi
On Tuesday 22 January 2008 15:20:25 Allison Randal via RT wrote:
> From http://osdir.com/ml/lib.libtom/2005-01/msg00010.html:
>
> "By default common symbols are not included in static
> archive table of contents. If you use the ranlib(1) -c
> option you can get Linux behavior."
>
> And from 'man
>From http://osdir.com/ml/lib.libtom/2005-01/msg00010.html:
"By default common symbols are not included in static
archive table of contents. If you use the ranlib(1) -c
option you can get Linux behavior."
And from 'man ranlib' on 10.4.11:
-c Include common symbols as definitions with respe
chromatic via RT wrote:
Does this happen after a 'make realclean' and recompilation?
In fact, it only happened when I ran 'make realclean' and recompiled.
I'd been happily running 'make' with no problems. I was surprised to see
the error pop up on the pdd17pmc branch after I merged, so went
On Monday 21 January 2008 01:09:29 Allison Randal wrote:
> In the past few weeks we've had an increasing number of "Undefined
> symbols" errors on OS X (Tiger). Previously it was only a handful of
> failing tests, but now it's preventing 'make' from completing,
> terminating with the following err
# New Ticket Created by Allison Randal
# Please include the string: [perl #50056]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50056 >
In the past few weeks we've had an increasing number of "Undefined
symbols" errors on
52 matches
Mail list logo
