[perl #50056] [BUG] Undefined symbols on OS X
Hearing no objections, am resolving ticket.
[perl #50056] [BUG] Undefined symbols on OS X
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, is described by Apple as appropriate for OS X 10.4, to which I had upgraded two years ago. The 2.5 version includes both gcc 3.3 and gcc 4.0.1. Allison also speculated that there might be some library corruption somewhere. So I signed up for an Apple Developer Connection online account and downloaded Xcode 2.5. (Hint: allocate 60-90 minutes for this process.) I then tried to configure Parrot by substituting in 4.0 instead of 3.3 in my shell script. And I got exactly the same failures as I had been getting since the PDD 17 branch was merged into trunk! Determining if your platform supports readline...dyld: lazy symbol binding failed: Symbol not found: _rl_get_keymap Referenced from: /Users/jimk/work/26335/./test Expected in: dynamic lookup dyld: Symbol not found: _rl_get_keymap Referenced from: /Users/jimk/work/26335/./test Expected in: dynamic lookup ...no. Feeling very frustrated, I began googling for the error message. It turns out I am the only person to report the '_rl_get_keymap' aspect of the error messages. However, focusing on the 'dyld: Symbol not found' aspect brought up several links where the problem -- not in Parrot -- was related to readline. I had installed readline 4.3-28 via Fink some time ago, but, curiously, it was never detected by Configure.pl -- even when I was using the non-throwing-warnings version of config/init/hints/darwin.pm that was in trunk before the PDD 17 merge. I decided to uninstall readline 4.3-28 and, since a more recent version (5.0-4) was available to install that. That finally did the trick. I was able to run Configure.pl -- now using gcc 4.0 -- and get the auto::readline step to run without throwing any warnings and have it correctly detect the presence of readline where Fink had installed it. Then, for good measure, I re-configured with gcc 3.3 instead of 4.0, but with the new readline -- and configured successfully there as well. My inference is that there was never a problem with gcc 3.3; the problem was found solely in some incompatibility between the post-PDD 17 version of config/init/hints/darwin.pm and the older version of readline I had on my disk. Since I now have an Apple-built gcc 4.0 compiler on my iBook, going forward I will be using that rather than 3.3. But since the problem was not 3.3 after all, I don't think we should abandon it and I will from time to time try to build with that version. If I hear no objection soon I will resolve this ticket. Thank you very much. kid51
Re: [perl #50056] [BUG] Undefined symbols on OS X: auto::readline throwing warnings during configuration
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 for me for the next 6 weeks. [...] Could we find out who committed what, when and why, so that we can discuss remedies? 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 remember resolving that. You reported all tests as passing in the PDD 17 branch before the merge. Allison
[perl #50056] [BUG] Undefined symbols on OS X
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 remember resolving that. No, it never was resolved. Even though I have had that TARGET set for weeks, whenever I applied what you were attempting I got those warnings during configuration. So I breathed a sigh of relief when you did not apply it to trunk. The failures reappeared after the PDD 17 branch was merged in -- and I'm not the only one reporting them. Andy Bach reported the same errors. You reported all tests as passing in the PDD 17 branch before the merge. I have to apologize for what was an incomplete and misleading report. Looking back on that report, I see that it did *not* come from Darwin; it came from Linux (because only on my Linux can I simply call 'perl Configure.pl'). And the tests that were run were the pre- and post-configuration and build tools tests activated by 'perl Configure.pl -test'. Regardless of whether or not I was getting the warnings during auto::readline, all those tests were passing. And the sort of things they test were unlikely to be affected by what you were doing in the PDD 17 branch. So we're in a dilemma. The things that some of us are doing to try to push forward our development on Darwin are breaking the Darwin configuration and build of some of the rest of us on that platform. (Cf. the problems I'm reporting with one of chromatic's patches in http://rt.perl.org/rt3/Ticket/Display.html?id=51912.) So, although I know the news is not pleasant, I do have to report that the merging in of that branch has messed up (at least at the level of warnings) the same way I was configuring for 1 year on my iBook. I don't know enough about this to provide a diagnosis, but I think it's at least a yellow flag in terms of our work on that OS. Jim Keenan
[perl #50056] [BUG] Undefined symbols on OS X
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 attached, undo.26309.hints.darwin.patch.txt
Index: config/init/hints/darwin.pm
===
--- config/init/hints/darwin.pm (revision 26379)
+++ config/init/hints/darwin.pm (working copy)
@@ -24,6 +24,9 @@
my $lib_dir = $conf-data-get('build_dir') . /blib/lib;
$ldflags .= -L$lib_dir;
$ccflags .= -pipe -fno-common -Wno-long-double ;
+$ccflags =~ s/-flat_namespace\s*//;
+$ldflags =~ s/-flat_namespace\s*//;
+$ldflags .= -flat_namespace ;
$conf-data-set(
darwin = 1,
@@ -34,10 +37,9 @@
share_ext = '.dylib',
load_ext= '.bundle',
link= 'c++',
-linkflags = '-undefined dynamic_lookup',
ld = 'c++',
-ld_share_flags = '-dynamiclib -undefined dynamic_lookup',
-ld_load_flags = '-bundle -undefined dynamic_lookup',
+ld_share_flags = '-dynamiclib -undefined suppress',
+ld_load_flags = '-bundle -undefined suppress',
memalign= 'some_memalign',
has_dynamic_linking = 1,
[perl #50056] [BUG] Undefined symbols on OS X: auto::readline throwing warnings during configuration
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. But somewhere between r26279 (Sun Mar 09) and r26357 (today, Thu Mar 13), someone committed some code to trunk which caused Configure.pl to throw warnings at the same location. This is what I got tonight: Determining if your platform supports readline...dyld: lazy symbol binding failed: Symbol not found: _rl_get_keymap Referenced from: /Users/jimk/work/parrot/./test Expected in: dynamic lookup dyld: Symbol not found: _rl_get_keymap Referenced from: /Users/jimk/work/parrot/./test Expected in: dynamic lookup ...no. I had installed readline via Fink and, prior to this recent commit, config/auto/readline.pm was correctly detecting it under /sw/lib/. Could we find out who committed what, when and why, so that we can discuss remedies? Thank you very much. kid51
[perl #50056] [BUG] Undefined symbols on OS X
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, as evidenced by this configuration done at r26335 -- one before that patch. Determining if your platform supports readline...dyld: lazy symbol binding failed: Symbol not found: _rl_get_keymap Referenced from: /Users/jimk/work/26335/./test Expected in: dynamic lookup dyld: Symbol not found: _rl_get_keymap Referenced from: /Users/jimk/work/26335/./test Expected in: dynamic lookup ...no. Determining if your platform supports gdbm.yes. [snip] Determining Parrot's revision...r26335.
[perl #50056] [BUG] Undefined symbols on OS X
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 gdbm.yes. Seeing if your configuration includes gettext..yes. Testing snprintf..done. Determining whether perldoc is installed...yes. Determining whether python is installed.yes, 2.3.5. Determining whether GNU m4 is installedyes. Determining whether (exuberant) ctags is installed..no. Determining Parrot's revision...r26306. So damage occurred between 26306 and 26335. kid51
[perl #50056] [BUG] Undefined symbols on OS X
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/26309/./test Expected in: dynamic lookup ...no. Determining if your platform supports gdbm.yes. Seeing if your configuration includes gettext..yes. Testing snprintf..done. Determining whether perldoc is installed...yes. Determining whether python is installed.yes, 2.3.5. r26309 | allison | 2008-03-11 05:50:21 -0400 (Tue, 11 Mar 2008) | 2 lines [pdd17pmc] Merging the pdd17pmc branch into trunk (r24435 to r26307).
[perl #50056] [BUG] Undefined symbols on OS X
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 = -lgdbm -ldbm -ldl -lm -lc init::miniparrot = -lgdbm -ldbm -ldl -lm -lc init::hints = -lgdbm -ldbm -lm -lc init::headers = -lgdbm -ldbm -lm -lc inter::progs = -lm inter::make = -lm inter::lex = -lm inter::yacc = -lm auto::gcc = -lm auto::backtrace = -lm auto::fink = -lm auto::msvc = -lm auto::attributes = -lm auto::warnings = -lm init::optimize = -lm inter::shlibs = -lm inter::libparrot = -lm inter::charset = -lm inter::encoding = -lm inter::types = -lm auto::ops = -lm auto::pmc = -lm auto::alignptrs = -lm auto::headers = -lm auto::sizes = -lm auto::byteorder = -lm auto::va_ptr = -lm auto::pack = -lm auto::format = -lm auto::isreg = -lm auto::arch = -lm auto::jit = -lm auto::cpu = -lm auto::funcptr = -lm auto::cgoto = -lm auto::inline = -lm auto::gc = -lm auto::memalign = -lm auto::signal = -lm auto::socklen_t = -lm auto::env = -lm auto::aio = -lm auto::gmp = -lm -lgmp auto::readline = -lm -lgmp auto::gdbm = -lm -lgmp auto::snprintf = -lm -lgmp auto::perldoc = -lm -lgmp auto::python = -lm -lgmp auto::m4 = -lm -lgmp auto::ctags = -lm -lgmp auto::revision = -lm -lgmp gen::icu = -lm -lgmp gen::config_h = -lm -lgmp gen::core_pmcs = -lm -lgmp gen::parrot_include = -lm -lgmp gen::languages = -lm -lgmp gen::makefiles = -lm -lgmp gen::platform = -lm -lgmp gen::config_pm = -lm -lgmp
[perl #50056] [BUG] Undefined symbols on OS X
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. (BTW: Are you okay with RT 50390?)
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 readline is not being found. I suspect the reason it's not finding readline is because -lreadline isn't specified in the test compile. OS X (and especially dynamic_lookup) is more strict about only searching for symbols from libraries explicitly included. Try manually adding -lreadline to the test compile in auto::readline and see what happens. (BTW: Are you okay with RT 50390?) Looks good. Thanks! Allison
[perl #50056] [BUG] Undefined symbols on OS X
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/readline.pm (revision 25380)
+++ config/auto/readline.pm (working copy)
@@ -57,6 +57,9 @@
# this code into a Parrot::Configure::Step::Methods method analogous to
# _handle_darwin_for_fink().
$self-_handle_darwin_for_macports($conf, $osname,
q{readline/readline.h});
+if ( $osname =~ /darwin/i ) {
+$conf-data-add( ' ', libs = '-lreadline' );
+}
$conf-cc_gen('config/auto/readline/readline.in');
my $has_readline = 0;
... and this is what I got:
Determining if your platform supports readline...dyld: lazy symbol
binding failed: Symbol not found: _rl_get_keymap
Referenced from: /Users/jimk/work/parrot/./test
Expected in: dynamic lookup
dyld: Symbol not found: _rl_get_keymap
Referenced from: /Users/jimk/work/parrot/./test
Expected in: dynamic lookup
...no.
kid51
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 generated Makefile, both LINKFLAGS and LDFLAGS should include the entry -L/sw/lib and CFLAGS should include the entry -I/sw/include. Do they? Allison
[perl #50056] [BUG] Undefined symbols on OS X
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.
Do they?
Allison
A good diagnostic question. They do not:
LINKFLAGS = -undefined dynamic_lookup -L/sw/lib -L/sw/lib
LD = /usr/bin/g++-3.3
LDFLAGS= -L/usr/local/lib -L/Users/jimk/work/parrot/blib/lib
-L/sw/lib -L/sw/lib
-L/sw/lib is duplicated on those lines with -I/sw/include is missing
from each.
This may be a problem with the code I wrote/adapted concerning Fink.
Here's some data from Parrot::Configure::Trace. First, here is how
'linkflags' is evolving around the crucial configuration steps:
{
'auto::aio' = '-undefined dynamic_lookup'
},
{
'auto::gmp' = '-undefined dynamic_lookup -L/sw/lib'
},
{
'auto::readline' = '-undefined dynamic_lookup -L/sw/lib'
},
{
'auto::gdbm' = '-undefined dynamic_lookup -L/sw/lib -L/sw/lib'
},
And here's how 'ldflags' is evolving around the same steps:
{
'auto::aio' = ' -L/usr/local/lib -L/Users/jimk/work/parrot/blib/lib'
},
{
'auto::gmp' = ' -L/usr/local/lib -L/Users/jimk/work/parrot/blib/lib
-L/sw/lib'
},
{
'auto::readline' = ' -L/usr/local/lib
-L/Users/jimk/work/parrot/blib/lib -L/sw/lib'
},
{
'auto::gdbm' = ' -L/usr/local/lib
-L/Users/jimk/work/parrot/blib/lib -L/sw/lib -L/sw/lib'
},
[perl #50056] [BUG] Undefined symbols on OS X
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_DEPRECATED -DHASATTRIBUTE_FORMAT
-DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN
-DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -falign-functions=16 -W
-Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual
-Wchar-subscripts -Wcomment -Wdisabled-optimization -Wformat-nonliteral
-Wformat-security -Wformat-y2k -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wimport -Winline
-Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-endif-labels -Wno-shadow
-Wno-unused -Wnonnull -Wpacked -Wparentheses -Wpointer-arith
-Wreturn-type -Wsequence-point -Wsign-compare -Wstrict-aliasing -Wswitch
-Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wwrite-strings'
},
{
'auto::gmp' = '-fno-common -no-cpp-precomp -pipe
-I/usr/local/include -pipe -fno-common -Wno-long-double
-DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT
-DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN
-DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -falign-functions=16 -W
-Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual
-Wchar-subscripts -Wcomment -Wdisabled-optimization -Wformat-nonliteral
-Wformat-security -Wformat-y2k -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wimport -Winline
-Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-endif-labels -Wno-shadow
-Wno-unused -Wnonnull -Wpacked -Wparentheses -Wpointer-arith
-Wreturn-type -Wsequence-point -Wsign-compare -Wstrict-aliasing -Wswitch
-Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wwrite-strings
-I/sw/include'
},
{
'auto::readline' = '-fno-common -no-cpp-precomp -pipe
-I/usr/local/include -pipe -fno-common -Wno-long-double
-DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT
-DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN
-DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -falign-functions=16 -W
-Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual
-Wchar-subscripts -Wcomment -Wdisabled-optimization -Wformat-nonliteral
-Wformat-security -Wformat-y2k -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wimport -Winline
-Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-endif-labels -Wno-shadow
-Wno-unused -Wnonnull -Wpacked -Wparentheses -Wpointer-arith
-Wreturn-type -Wsequence-point -Wsign-compare -Wstrict-aliasing -Wswitch
-Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wwrite-strings
-I/sw/include'
},
{
'auto::gdbm' = '-fno-common -no-cpp-precomp -pipe
-I/usr/local/include -pipe -fno-common -Wno-long-double
-DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT
-DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN
-DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -falign-functions=16 -W
-Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual
-Wchar-subscripts -Wcomment -Wdisabled-optimization -Wformat-nonliteral
-Wformat-security -Wformat-y2k -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wimport -Winline
-Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-endif-labels -Wno-shadow
-Wno-unused -Wnonnull -Wpacked -Wparentheses -Wpointer-arith
-Wreturn-type -Wsequence-point -Wsign-compare -Wstrict-aliasing -Wswitch
-Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wwrite-strings
-I/sw/include -I/sw/include'
},
Now, an obvious error is the doubling of the attribute at auto::gdbm for
each of the 3 flags. I have an idea of how that happened.
from lib/Parrot/Configure/Step/Methods.pm:
sub _handle_darwin_for_fink {
my ($self, $conf, $osname, $file) = @_;
if ( $osname =~ /darwin/ ) {
my $fink_lib_dir= $conf-data-get('fink_lib_dir');
my $fink_include_dir= $conf-data-get('fink_include_dir');
if ( (defined $fink_lib_dir) (defined $fink_include_dir) ) {
if ( -f $fink_include_dir/$file ) {
$conf-data-add( ' ', linkflags = -L$fink_lib_dir );
$conf-data-add( ' ', ldflags = -L$fink_lib_dir );
$conf-data-add( ' ', ccflags = -I$fink_include_dir );
}
}
}
return 1;
}
However, the spewing problem occured at auto::readline -- one step
*before* the first superfluous addition of a flag.
[perl #50056] [BUG] Undefined symbols on OS X
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 to config/init/hints/darwin.pm and my anti-duplication patch to lib/Parrot/Configure/Step/Methods.pm. 'make' completed successfully but slowed my iBook *drastically* at src/ops/core_ops_cg.c src/ops/debug.ops: In function `cg_core': src/ops/debug.ops:103: warning: null argument where non-null required (arg 2) src/ops/debug.ops:113: warning: null argument where non-null required (arg 2) src/ops/core_ops_cgp.c src/ops/debug.ops: In function `cgp_core': src/ops/debug.ops:103: warning: null argument where non-null required (arg 2) src/ops/debug.ops:113: warning: null argument where non-null required (arg 2) kid51 As you requested, we'll start with some tests of the configuration tools. t/configure/001-optionsok t/configure/002-messages...ok t/configure/003-steplist...ok t/configure/004-configure..ok t/configure/005-run_one_step...ok t/configure/006-bad_step...ok t/configure/007-verbose_twook t/configure/008-verbose_step_numberok t/configure/009-verbose_step_regex.ok t/configure/010-verbose_step_num_uncalled..ok t/configure/011-no_description.ok t/configure/012-verboseok t/configure/013-dieok t/configure/015-no_return..ok t/configure/016-no_return_but_result...ok t/configure/017-revision_from_cacheok t/configure/018-revision_to_cache..ok t/configure/019-versionok t/configure/020-versionok t/configure/021-versionok t/configure/022-versionok t/configure/023-versionok t/configure/024-versionok t/configure/025-options_test...ok t/configure/026-options_test...ok t/configure/027-option_or_data.ok t/configure/028-option_or_data.ok t/configure/029-option_or_data.ok t/configure/030-option_or_data.ok t/configure/031-base...ok t/configure/032-data...ok t/configure/033-step...ok t/configure/034-step...ok t/configure/035-step...ok t/configure/036-config_steps...ok t/configure/037-run_single_stepok t/configure/038-run_single_stepok t/configure/039-run_single_stepok t/configure/040-return_undef...ok t/configure/041-return_undef...ok t/configure/042-list_of_steps..ok t/configure/043-verbose_step_name..ok t/configure/044-slurp_file.ok t/configure/045-generated_file_header..ok t/configure/046-inter..ok t/configure/047-inter..ok t/configure/048-return_result_undefok t/configure/050-fatal..ok t/configure/051-fatal_step.ok t/configure/052-fatal_step.ok t/configure/053-fatal_step.ok t/configure/054-fatal_step.ok t/configure/055-fatal_step.ok t/configure/056-fatal_step.ok t/configure/057-fatal_step.ok t/configure/058-fatal_step.ok t/configure/059-silent.ok t/configure/060-silent.ok t/steps/init_manifest-01...ok t/steps/init_manifest-02...ok t/steps/init_defaults-01...ok t/steps/init_defaults-02...ok t/steps/init_defaults-03...ok t/steps/init_defaults-04...ok t/steps/init_install-01ok t/steps/init_install-02ok t/steps/init_miniparrot-01.ok t/steps/init_hints-01..ok t/steps/init_hints-02..ok t/steps/init_hints-03..ok t/steps/init_hints-04..ok t/steps/init_headers-01ok t/steps/inter_progs-01.ok t/steps/inter_progs-02.ok t/steps/inter_progs-03.ok t/steps/inter_progs-04.ok t/steps/inter_make-01..ok t/steps/inter_make-02..ok t/steps/inter_lex-01...ok t/steps/inter_lex-02...ok
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 -lreadline included? Allison
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 $ MACOSX_DEPLOYMENT_TARGET=10.4 [parrot] 567 $ echo $MACOSX_DEPLOYMENT_TARGET 10.4 You also need to export the variable. Assuming you have bash or zsh, try: $ export MACOSX_DEPLOYMENT_TARGET=10.4 HTH, Paul
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 environment variable in your startup script. #!/bin/sh MACOSX_DEPLOYMENT_TARGET=10.3 CC=/usr/bin/gcc-3.3 [...] Then, try not using the startup script and simply running: make realclean perl Configure.pl make (The default Parrot config hints should work on the default Apple setup. It's been a year since you posted to Perl Monks with the initial problem that made you force version 3.3 for the Parrot compile, and a lot has changed. Many of us are using gcc 4.0.1 now.) Allison
[perl #50056] [BUG] Undefined symbols on OS X
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 duplicate the failure when I use your startup script. First, try setting the environment variable in your startup script. #!/bin/sh MACOSX_DEPLOYMENT_TARGET=10.3 CC=/usr/bin/gcc-3.3 [...] 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=$CX --without-icu \ --test \ --configure_trace \ $@ No improvement in results: Test Summary Report --- t/steps/auto_warnings-01.t (Wstat: 1792 Tests: 15 Failed: 0) Non-zero exit status: 7 Parse errors: Bad plan. You planned 22 tests but ran 15. t/steps/auto_warnings-02.t (Wstat: 1792 Tests: 15 Failed: 0) Non-zero exit status: 7 Parse errors: Bad plan. You planned 22 tests but ran 15. t/steps/auto_warnings-03.t (Wstat: 1792 Tests: 15 Failed: 0) Non-zero exit status: 7 Parse errors: Bad plan. You planned 22 tests but ran 15. t/steps/auto_warnings-04.t (Wstat: 2048 Tests: 15 Failed: 0) Non-zero exit status: 8 Parse errors: Bad plan. You planned 23 tests but ran 15. t/steps/auto_warnings-05.t (Wstat: 2048 Tests: 15 Failed: 0) Non-zero exit status: 8 Parse errors: Bad plan. You planned 23 tests but ran 15. t/steps/auto_warnings-06.t (Wstat: 2304 Tests: 15 Failed: 0) Non-zero exit status: 9 Parse errors: Bad plan. You planned 24 tests but ran 15. t/steps/auto_warnings-07.t (Wstat: 1792 Tests: 15 Failed: 0) Non-zero exit status: 7 Parse errors: Bad plan. You planned 22 tests but ran 15. t/steps/auto_warnings-08.t (Wstat: 2048 Tests: 15 Failed: 0) Non-zero exit status: 8 Parse errors: Bad plan. You planned 23 tests but ran 15. Files=257, Tests=3651, 154 wallclock secs ( 4.45 usr 4.38 sys + 71.98 cusr 24.05 csys = 104.86 CPU) Result: FAIL Failed 8/257 test programs. 0/3651 subtests failed. $ ./myconfigure.sh 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 passed in the `--ask' flag on the command line, in which case I'll prompt you for a few pieces of info. Since you're running this program, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking MANIFEST.done. Setting up Configure's default values.done. Setting up installation paths.done. Tweaking settings for miniparrot...skipped. Loading platform and local hints filesdone. Finding header files distributed with Parrot..done. Determining what C compiler and linker to use...Compilation failed with '/usr/bin/gcc-3.3' I then attempted to 'make realclean' -- but there was no need to -- and then attempted reconfiguration: [parrot] 507 $ make realclean make: *** No rule to make target `realclean'. Stop. [parrot] 508 $ perl Configure.pl --configure_trace 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 passed in the `--ask' flag on the command line, in which case I'll prompt you for a few pieces of info. Since you're running this program, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking MANIFEST.done. Setting up Configure's default values.done. Setting up installation paths.done. Tweaking settings for miniparrot...skipped. Loading platform and local hints filesdone. Finding header files distributed with Parrot..done. Determining what C compiler and linker to use...Compilation failed with 'cc' [snip] Then, try not using the startup script and simply running: make realclean perl Configure.pl make (The default Parrot config hints should work on the default Apple setup. It's been a year since you posted to Perl Monks with the initial problem that made you force version 3.3 for the Parrot compile, and a lot has changed. Many of us are using gcc 4.0.1 now.) Does that mean (a) that
Re: [perl #50056] [BUG] Undefined symbols on OS X
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=$CX --without-icu \ --test \ --configure_trace \ $@ Right, but I'm saying to set it in the startup script, rather than setting it in the command-line environment before you run the script. Unless you 'export' the environment variable setting, or set it on the same line as the call to the script, it won't be set inside the startup script (put an 'echo $MACOSX_DEPLOYMENT_TARGET' line inside your startup script and you'll see what I mean). If you set the environment variable inside the script, then it's guaranteed to be right (and you won't have to think about it every time you run the script). (The default Parrot config hints should work on the default Apple setup. It's been a year since you posted to Perl Monks with the initial problem that made you force version 3.3 for the Parrot compile, and a lot has changed. Many of us are using gcc 4.0.1 now.) Does that mean (a) that you are no longer supporting Parrot with gcc-3.3 on Darwin and (b) that I have to go out and buy a new computer if I want a Mac with gcc-4.0.1? Nope, it means I'm curious if compiling Parrot on your computer is now supported by 4.0.1. The hints file for darwin can perform more checks based on compiler version and OS version if it turns out that different hints are required for certain versions of the compiler. In this case simply setting MACOSX_DEPLOYMENT_TARGET should do the trick. Allison
[perl #50056] [BUG] Undefined symbols on OS X
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-precomp -pipe -I/usr/local/include -pipe -fno-common -Wno-long-double -I./include -c test.c /usr/bin/g++-3.3 -undefined dynamic_lookup test.o -o test -lm ld: flag: -undefined dynamic_lookup can't be used with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 Compilation failed with '/usr/bin/gcc-3.3' Next, with just 'perl Configure.pl --verbose-step=7 --nomanicheck': 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 cc -fno-common -no-cpp-precomp -pipe -I/usr/local/include -pipe -fno-common -Wno-long-double -I./include -c test.c c++ -undefined dynamic_lookup test.o -o test -lm /usr/bin/ld: flag: -undefined dynamic_lookup can't be used with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 collect2: ld returned 1 exit status Compilation failed with 'cc'
Re: [perl #50056] [BUG] Undefined symbols on OS X
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-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./include -c test.c /usr/bin/g++-3.3 -undefined dynamic_lookup test.o -o test -lm ld: flag: -undefined dynamic_lookup can't be used with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 Note the last line. You still have the environment variable set to 10.1. You probably forgot to export MACOSX_DEPLOYMENT_TARGET. You should probably set it to 10.3 right in the hints file. Or at least check it in the hints file and die with an informative error message. -- Andy Dougherty [EMAIL PROTECTED]
[perl #50056] [BUG] Undefined symbols on OS X
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 passed in the `--ask' flag on the command line, in which case I'll prompt you for a few pieces of info. Since you're running this program, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking MANIFEST..skipped. Setting up Configure's default values.done. Setting up installation paths.done. Tweaking settings for miniparrot...skipped. Loading platform and local hints filesdone. Finding header files distributed with Parrot..done. 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./include -c test.c /usr/bin/g++-3.3 -undefined dynamic_lookup test.o -o test -lm ld: flag: -undefined dynamic_lookup can't be used with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 Compilation failed with '/usr/bin/gcc-3.3'
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 resetting to your default environment values. Allison
[perl #50056] [BUG] Undefined symbols on OS X
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 still failing the 4th test, but it fails the same
way on Linux when I unTODO it.) It also runs 'make perl6' without errors.
If you're running some flavor of OS X, please test this patch. (Let me
know if you're running a version before 10.3. It was released October
2003, which is significantly before our versions released in the past 2
years cutoff of support for the 1.0 release of Parrot.)
I've wanted to get rid of the '-flat_namespace' hack for a long time now.
Index: config/init/hints/darwin.pm
===
--- config/init/hints/darwin.pm (revision 25264)
+++ config/init/hints/darwin.pm (working copy)
@@ -24,9 +24,6 @@
my $lib_dir = $conf-data-get('build_dir') . /blib/lib;
$ldflags .= -L$lib_dir;
$ccflags .= -pipe -fno-common -Wno-long-double ;
-$ccflags =~ s/-flat_namespace\s*//;
-$ldflags =~ s/-flat_namespace\s*//;
-$ldflags .= -flat_namespace ;
$conf-data-set(
darwin = 1,
@@ -37,9 +34,10 @@
share_ext = '.dylib',
load_ext= '.bundle',
link= 'c++',
+linkflags = '-undefined dynamic_lookup',
ld = 'c++',
-ld_share_flags = '-dynamiclib -undefined suppress',
-ld_load_flags = '-bundle -undefined suppress',
+ld_share_flags = '-dynamiclib -undefined dynamic_lookup',
+ld_load_flags = '-bundle -undefined dynamic_lookup',
memalign= 'some_memalign',
has_dynamic_linking = 1,
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 the first thing I tried. Unsuccessful. Odd. It should work. I submitted a patch last week to fix it (filed under [perl #50066] .) If we have to mess around with linking issues anyway, we might as well spend the effort on the dynamic library and get it right the first time. Oh, agreed. I just meant that we didn't have to be you. But fixing it as you did, by understanding what all the different flags actually do, and localizing it all in the darwin hints file, instead of doing half of it in the hints file and and half in pbc_to_exe, was indeed the right approach. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #50056] [BUG] Undefined symbols on OS X
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)
[perl #50056] [BUG] Undefined symbols on OS X
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) Excellent, I have intel-darwin 10.4.11, so that covers another platform. Allison
[perl #50056] [BUG] Undefined symbols on OS X
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 always proceed on my iBook. All of the t/steps/auto_warnings*.t tests failed at the same point. Failed TestStat Wstat Total Fail List of Failed --- t/steps/auto_warnings-01.t7 179222 14 16-22 t/steps/auto_warnings-02.t7 179222 14 16-22 t/steps/auto_warnings-03.t7 179222 14 16-22 t/steps/auto_warnings-04.t8 204823 16 16-23 t/steps/auto_warnings-05.t8 204823 16 16-23 t/steps/auto_warnings-06.t9 230424 18 16-24 t/steps/auto_warnings-07.t7 179222 14 16-22 t/steps/auto_warnings-08.t8 204823 16 16-23 Here's the output of 'prove -v' on the first: [parrot] 509 $ prove -v t/steps/auto_warnings-01.t t/steps/auto_warnings-011..22 ok 1 - use config::init::defaults; ok 2 - use config::init::hints; ok 3 - use config::inter::progs; ok 4 - use config::auto::warnings; ok 5 - init::defaults constructor returned defined value ok 6 - The object isa init::defaults ok 7 - init::defaults has description ok 8 - init::defaults runstep() returned defined value ok 9 - init::hints constructor returned defined value ok 10 - The object isa init::hints ok 11 - init::hints has description ok 12 - init::hints runstep() returned defined value ok 13 - inter::progs constructor returned defined value ok 14 - The object isa inter::progs ok 15 - inter::progs has description Compilation failed with 'cc' # Looks like you planned 22 tests but only ran 15. dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 16-22 Failed 7/22 tests, 68.18% okay Failed TestStat Wstat Total Fail List of Failed --- t/steps/auto_warnings-01.t 255 6528022 14 16-22 Failed 1/1 test scripts. 7/22 subtests failed. Files=1, Tests=22, 5 wallclock secs ( 0.34 cusr + 0.21 csys = 0.55 CPU) Failed 1/1 test programs. 7/22 subtests failed. So the patch is causing the call to inter::progs in this test to fail. Now, this could be due to defect in the construction of the test -- as Andy Dougherty has pointed out 1 times and as I hope eventually to fix. But I then tried configuration without the --test option. This was my result: Checking MANIFEST.done. Setting up Configure's default values.done. Setting up installation paths.done. Tweaking settings for miniparrot...skipped. Loading platform and local hints filesdone. Finding header files distributed with Parrot..done. 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-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./include -c test.c /usr/bin/g++-3.3 -undefined dynamic_lookup test.o -o test -lm ld: flag: -undefined dynamic_lookup can't be used with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 Compilation failed with '/usr/bin/gcc-3.3' So the patch prevents me from building with the C-compiler I know I have to use. Back to the drawing boards.
Re: [perl #50056] [BUG] Undefined symbols on OS X
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-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./include -c test.c /usr/bin/g++-3.3 -undefined dynamic_lookup test.o -o test -lm ld: flag: -undefined dynamic_lookup can't be used with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 Compilation failed with '/usr/bin/gcc-3.3' So the patch prevents me from building with the C-compiler I know I have to use. Back to the drawing boards. It looks like the flag has a problem with the environment variable (not the compiler) and others appear to have had the same issue: http://mail.python.org/pipermail/pythonmac-sig/2005-October/015190.html http://reprocessed.org/blog/archives/2005/07/27/compiling_postgresql_and_psycopg_119_on_mac_os_x_104_tiger.html http://lua-users.org/lists/lua-l/2005-03/msg00349.html Could you try setting MACOSX_DEPLOYMENT_TARGET to 10.4 to see if that fixes the problem? - David -- The implication--that something which I and most undergraduates could master without extraordinary pains would have been too hard for Plato, Dante, Hooker, and Pascal--did not yet strike me as absurd. -- C.S. Lewis, Miracles
[perl #50056] [BUG] Undefined symbols on OS X
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?
[perl #50056] [BUG] Undefined symbols on OS X
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 [parrot] 568 $ patch -p0 config/init/hints/darwin.pm ~/learn/parrot/patches/darwin_full_dynamic_symbol_lookup.patch patching file config/init/hints/darwin.pm [parrot] 571 $ ./myconfigure.sh Parrot Version 0.5.2 Configure 2.0 Copyright (C) 2001-2008, The Perl Foundation. [snip] Finding header files distributed with Parrot..done. 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./include -c test.c /usr/bin/g++-3.3 -undefined dynamic_lookup test.o -o test -lm ld: flag: -undefined dynamic_lookup can't be used with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 Compilation failed with '/usr/bin/gcc-3.3' Setting the environmental variable apparently didn't stick.
Re: [perl #50056] [BUG] Undefined symbols on OS X
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./include -c test.c /usr/bin/g++-3.3 -undefined dynamic_lookup test.o -o test -lm ld: flag: -undefined dynamic_lookup can't be used with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 Compilation failed with '/usr/bin/gcc-3.3' The MACOSX_DEPLOYMENT_TARGET environment variable needs to be set to 10.3 instead of 10.1. (This is the version compatibility I mentioned.) Allison
[perl #50056] [BUG] Undefined symbols on OS X
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 between the test case and Parrot's compilation process, seeing if I can knock out the problem. Also helpful are the -whatsloaded and -whyload flags in gcc on darwin, which show that the .o file that defines the missing symbol (src/embed.o) is actually loaded in libparrot.dylib (to resolve symbol _Parrot_loadbc), but somehow the symbol _Parrot_set_executable_name is not included. darwin-gcc-libtest.tgz Description: Unix tar archive
[perl #50056] [BUG] Undefined symbols on OS X
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 lookup. gdb reports: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0001d000 0x0100a79a in string_make_direct (interp=0x400440, buffer=0x5474 , len=467200, encoding=0x400920, charset=0x400ab0, flags=0) at src/string.c:634 warning: Source file is more recent than executable. 634 real_exception(interp, NULL, UNIMPLEMENTED, (gdb) bt #0 0x0100a79a in string_make_direct (interp=0x400440, buffer=0x5474 , len=467200, encoding=0x400920, charset=0x400ab0, flags=0) at src/string.c:634 #1 0x0100a6b9 in string_make (interp=0x400440, buffer=0x5474 , len=467200, charset_name=0x1245a24 ascii, flags=0) at src/string.c:593 #2 0x010caff3 in PF_fetch_string (interp=0x400440, pf=0x413b80, cursor=0x5c6348) at src/packfile/pf_items.c:552 #3 0x0105fa1c in shift_opcode_string (interp=0x400440, io=0x4139f0) at src/pmc_freeze.c:744 #4 0x01024a6d in hash_thaw (interp=0x400440, hash=0x413cc0, info=0xbfffed44) at src/hash.c:331 #5 0x01024d3b in parrot_hash_visit (interp=0x400440, hash=0x413cc0, pinfo=0xbfffed44) at src/hash.c:408 #6 0x011a44bc in Parrot_Hash_visit (interp=0x400440, pmc=0x5dadc0, info=0xbfffed44) at ./src/pmc/hash.pmc:1021 #7 0x01060d4e in visit_loop_todo_list (interp=0x400440, current=0x5dadc0, info=0xbfffed44) at src/pmc_freeze.c:1432 #8 0x01061080 in run_thaw (interp=0x400440, image=0x5c6338, what=VISIT_THAW_NORMAL) at src/pmc_freeze.c:1554 #9 0x010612d0 in Parrot_thaw (interp=0x400440, image=0x5c6338) at src/pmc_freeze.c:1663 #10 0x01024319 in parrot_set_config_hash_interpreter (interp=0x400440) at src/global_setup.c:83 #11 0x010244ff in init_world (interp=0x400440) at src/global_setup.c:140 #12 0x010160cb in Parrot_init (interp=0x400440) at src/embed.c:113 #13 0x0102bccb in make_interpreter (parent=0x0, flags=0) at src/inter_create.c:172 #14 0x01016099 in Parrot_new (parent=0x0) at src/embed.c:74 #15 0x220b in main () 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 working directories, so I'm not blocked by 'make' failing, and can get work done. Allison Index: tools/dev/pbc_to_exe_gen.pl === --- tools/dev/pbc_to_exe_gen.pl (revision 25264) +++ tools/dev/pbc_to_exe_gen.pl (working copy) @@ -351,6 +351,11 @@ .local string link link = ld link .= ' ' + +unless osname == 'darwin' goto not_darwin + link .= '-undefined dynamic_lookup ' +not_darwin: + link .= ld_out link .= exefile link .= ' '
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 working directories, so I'm not blocked by 'make' failing, and can get work done. No seggie here, 32-bit x86 Ubuntu. -- c
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 link link = ld link .= ' ' + +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 earlier. It doesn't look sustainable, maintainable, or even likely to be right in the long run. I can't test any of this myself, and it may be that gcc/ld isn't quite getting the symbol hiding stuff right anyway. What I'd be tempted to do is rip all the hiding stuff and the 'undefined suppress' out of the darwin hints and go back to the static build. The dynamic build doesn't buy you anything anyway. You can't install it, it doesn't make parrot run any faster, and it doesn't save you significantly on disk space since there aren't lots of executables embedding the parrot interpreter. It's just wasting your time. 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. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 earlier. It doesn't look sustainable, maintainable, or even likely to be right in the long run. I can't test any of this myself, and it may be that gcc/ld isn't quite getting the symbol hiding stuff right anyway. I admit I'm eager to be able compile Parrot (I can't really work on any other part of Parrot until I can compile it), but adding '-undefined dynamic_lookup' isn't a naive hack just to get it to compile. (Adding '-undefined suppress' would be.) From 'man ld': -undefined dynamic_lookup can also be used to allow any undefined symbols to be looked up dynamically at runtime. ...at execution time the dynamic linker will search that umbrella framework's sub-frameworks, sub-umbrellas and sub-libraries for those references. Some documentation on symbols in OS X: http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachOTopics/Articles/executing_files.html What I'd be tempted to do is rip all the hiding stuff and the 'undefined suppress' out of the darwin hints and go back to the static build. Using '-undefined suppress' (or '-undefined dynamic_lookup') when linking libparrot.dylib is necessary for libraries that Parrot uses, not just for Parrot internals. See http://mail-index4.netbsd.org/pkgsrc-bugs/2006/02/05/0039.html, which was also an Undefined symbol: _environ error, the same as Parrot gets if you leave '-undefined' set to the default '-undefined error'. Actually, in most places I read, it's recommended to use '-undefined dynamic_lookup' without '-flat_namespace'. It doesn't work before 10.3, but that seems like an acceptable loss. The dynamic build doesn't buy you anything anyway. You can't install it, it doesn't make parrot run any faster, and it doesn't save you significantly on disk space since there aren't lots of executables embedding the parrot interpreter. It's just wasting your time. 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 the first thing I tried. Unsuccessful. If we have to mess around with linking issues anyway, we might as well spend the effort on the dynamic library and get it right the first time. (There is an advantage to not requiring everyone who embeds Parrot to statically compile it into their program. See http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLibraries/Articles/OverviewOfDynamicLibraries.html.) Allison
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 the change in relation to the
failure starting. But, changing config/init/hints/darwin.pm back to
static by default, with a 'realclean' recompile doesn't work either.
Still get Undefined symbols errors:
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 $(LIBPARROT_STATIC) -lm
-lgmp -lreadline /Users/allison/projects/svn/parrot/src/parrot_config.o
sh: line 1: LIBPARROT_STATIC: command not found
/usr/bin/ld: Undefined symbols:
_PackFile_fixup_subs
[...]
collect2: ld returned 1 exit status
linking failed
current instr.: 'link_file' pc 752 (pbc_to_exe.pir:365)
called from Sub 'main' pc 124 (pbc_to_exe.pir:32)
It does work if I manually substitute blib/lib/libparrot.a for
LIBPARROT_STATIC in the compile command-line:
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 blib/lib/libparrot.a -lm
-lgmp -lreadline /Users/allison/projects/svn/parrot/src/parrot_config.o
This is interesting as it's the same problem I'm having on Solaris:
$(LIBPARROT_STATIC) isn't getting expanded. Except Solaris complains
that the '(' shouldn't be there. See RT#50066.
Paul
[perl #50056] [BUG] Undefined symbols on OS X
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/lib -lparrot -L/Users/allison/projects/svn/parrot/blib/lib -lm -lgmp -lreadline /Users/allison/projects/svn/parrot/src/parrot_config.o /Users/allison/projects/svn/parrot/src/embed.o /Users/allison/projects/svn/parrot/src/debug.o /Users/allison/projects/svn/parrot/src/global_setup.o /Users/allison/projects/svn/parrot/src/library.o /Users/allison/projects/svn/parrot/src/encoding.o /Users/allison/projects/svn/parrot/src/charset.o /Users/allison/projects/svn/parrot/src/platform.o /Users/allison/projects/svn/parrot/src/charset/iso-8859-1.o /Users/allison/projects/svn/parrot/src/charset/ascii.o /Users/allison/projects/svn/parrot/src/charset/tables.o /Users/allison/projects/svn/parrot/src/charset/unicode.o /Users/allison/projects/svn/parrot/src/charset/binary.o /Users/allison/projects/svn/parrot/src/encodings/fixed_8.o /Users/allison/projects/svn/parrot/src/encodings/utf16.o /Users/allison/projects/svn/parrot/src/encodings/utf8.o /Users/allison/projects/svn/parrot/src/encodings/ucs2.o /Users/allison/projects/svn/parrot/src/inter_run.o /Users/allison/projects/svn/parrot/src/inter_create.o /Users/allison/projects/svn/parrot/src/inter_misc.o /Users/allison/projects/svn/parrot/src/inter_call.o /Users/allison/projects/svn/parrot/src/trace.o /Users/allison/projects/svn/parrot/src/hll.o /Users/allison/projects/svn/parrot/src/vtables.o /Users/allison/projects/svn/parrot/src/gc/resources.o /Users/allison/projects/svn/parrot/src/gc/dod.o /Users/allison/projects/svn/parrot/src/gc/memory.o /Users/allison/projects/svn/parrot/src/gc/smallobject.o /Users/allison/projects/svn/parrot/src/gc/register.o /Users/allison/projects/svn/parrot/src/atomic/gcc_x86.o /Users/allison/projects/svn/parrot/src/stm/backend.o /Users/allison/projects/svn/parrot/src/stm/waitlist.o /Users/allison/projects/svn/parrot/src/thread.o /Users/allison/projects/svn/parrot/src/packfile.o /Users/allison/projects/svn/parrot/src/packfile/pf_items.o /Users/allison/projects/svn/parrot/src/scheduler.o /Users/allison/projects/svn/parrot/src/headers.o /Users/allison/projects/svn/parrot/src/sub.o /Users/allison/projects/svn/parrot/src/objects.o /Users/allison/projects/svn/parrot/src/oo.o /Users/allison/projects/svn/parrot/src/cpu_dep.o /Users/allison/projects/svn/parrot/src/pmc.o /Users/allison/projects/svn/parrot/src/tsq.o /Users/allison/projects/svn/parrot/src/exceptions.o /Users/allison/projects/svn/parrot/src/builtin.o /Users/allison/projects/svn/parrot/compilers/imcc/parser_util.o /Users/allison/projects/svn/parrot/compilers/imcc/imcparser.o /Users/allison/projects/svn/parrot/compilers/imcc/imclexer.o /Users/allison/projects/svn/parrot/compilers/imcc/symreg.o /Users/allison/projects/svn/parrot/compilers/imcc/optimizer.o /Users/allison/projects/svn/parrot/compilers/imcc/imc.o /Users/allison/projects/svn/parrot/compilers/imcc/pbc.o /Users/allison/projects/svn/parrot/compilers/imcc/reg_alloc.o /Users/allison/projects/svn/parrot/compilers/imcc/sets.o /Users/allison/projects/svn/parrot/compilers/imcc/cfg.o /Users/allison/projects/svn/parrot/compilers/imcc/pcc.o /Users/allison/projects/svn/parrot/compilers/imcc/debug.o /Users/allison/projects/svn/parrot/compilers/imcc/instructions.o /Users/allison/projects/svn/parrot/src/pic.o /Users/allison/projects/svn/parrot/src/pic_jit.o /Users/allison/projects/svn/parrot/src/interpreter.o /Users/allison/projects/svn/parrot/src/warnings.o /Users/allison/projects/svn/parrot/src/nci.o /Users/allison/projects/svn/parrot/src/intlist.o /Users/allison/projects/svn/parrot/src/ops/core_ops_cgp.o /Users/allison/projects/svn/parrot/src/ops/core_ops_switch.o /Users/allison/projects/svn/parrot/src/ops/core_ops_cg.o /Users/allison/projects/svn/parrot/src/ops/core_ops.o /Users/allison/projects/svn/parrot/src/runops_cores.o /Users/allison/projects/svn/parrot/src/utils.o /Users/allison/projects/svn/parrot/src/io/io.o /Users/allison/projects/svn/parrot/src/io/io_passdown.o /Users/allison/projects/svn/parrot/src/io/io_mmap.o /Users/allison/projects/svn/parrot/src/io/io_string.o /Users/allison/projects/svn/parrot/src/io/io_utf8.o /Users/allison/projects/svn/parrot/src/io/io_buf.o /Users/allison/projects/svn/parrot/src/io/io_unix.o /Users/allison/projects/svn/parrot/src/io/io_layers.o /Users/allison/projects/svn/parrot/src/byteorder.o /Users/allison/projects/svn/parrot/src/hash.o /Users/allison/projects/svn/parrot/src/core_pmcs.o /Users/allison/projects/svn/parrot/src/pmc/*.o
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 looks like the same problem I reported and fixed in [perl #49314] AutoReply: [PATCH] pbc_to_exe should list libraries last Looks like it's broken again. The fix is probably to just move src/parrot_config.o *before* the libraries. Even if that doesn't fix it for OS X, it's likely to be required on Unix systems with traditional linker behavior. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 -Lblib/lib -lparrot src/parrot_config.o $(O_FILES) This looks like the same problem I reported and fixed in [perl #49314] AutoReply: [PATCH] pbc_to_exe should list libraries last Looks like it's broken again. The fix is probably to just move src/parrot_config.o *before* the libraries. Even if that doesn't fix it for OS X, it's likely to be required on Unix systems with traditional linker behavior. Oops. Reading the original bug report more carefully, 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/lib -lparrot -L/Users/allison/projects/svn/parrot/blib/lib -lm -lgmp -lreadline /Users/allison/projects/svn/parrot/src/parrot_config.o /usr/bin/ld: Undefined symbols: _Parrot_set_executable_name collect2: ld returned 1 exit status 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 looks like something is going on to specifically hide symbols, but I have no idea how Mac OS works in this regard. Still, the reordering ought to be done. parrot_config.o ought to appear *before* -lparrot. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 looks like something is going on to specifically hide symbols, but I have no idea how Mac OS works in this regard. We should be using -fvisibility=hidden with GCC 4.x on Mac OS X, which may be causing the problem. Of concern to me right now is that I'm using GCC 4.x on Linux and that flag's not in my Makefile, so something that touched the GCC attribute detection recently might have caused things to go gooey kablooie. -- c
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 already when it encountered -lparrot. ?This indeed looks like something is going on to specifically hide symbols, but I have no idea how Mac OS works in this regard. We should be using -fvisibility=hidden with GCC 4.x on Mac OS X, which may be causing the problem. Of concern to me right now is that I'm using GCC 4.x on Linux and that flag's not in my Makefile, so something that touched the GCC attribute detection recently might have caused things to go gooey kablooie. The -fvisibility=hidden flag is commented out in config/auto/warnings.pm, so nobody should be seeing it. There are a number of flags set in hints/darwin.pm, however: $ccflags .= -pipe -fno-common -Wno-long-double ; $ccflags =~ s/-flat_namespace\s*//; $ldflags =~ s/-flat_namespace\s*//; $ldflags .= -flat_namespace ; $conf-data-set( darwin = 1, ccflags = $ccflags, ldflags = $ldflags, ccwarn = -Wno-shadow, libs= $libs, share_ext = '.dylib', load_ext= '.bundle', link= 'c++', ld = 'c++', ld_share_flags = '-dynamiclib -undefined suppress', ld_load_flags = '-bundle -undefined suppress', I'll guess that those flags are enabling whatever is going on. Alas I don't have any familiarity with the relevant issues (though I have read enough to know that the behavior may be different in different versions of Mac OS X 10.x). Someone with an actual Mac OS X 10.x machine is going to have to read the man pages, experiment around, and figure out what's going on. -- Andy Dougherty [EMAIL PROTECTED]
[perl #50056] [BUG] Undefined symbols on OS X
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 respect to the table of contents. This is seldom the intended behavior for linking from a library, as it forces the linking of a library member just because it uses an uninitialized global that is undefined at that point in the linking. This option is included only because this was the original behavior of ranlib. This option is not the default.
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 ranlib' on 10.4.11: -c Include common symbols as definitions with respect to the table of contents. This is seldom the intended behavior for linking from a library, as it forces the linking of a library member just because it uses an uninitialized global that is undefined at that point in the linking. This option is included only because this was the original behavior of ranlib. This option is not the default. Are you building a static or a shared binary? Did this problem only show up after Coke switched the default to shared? -- c
[perl #50056] [BUG] Undefined symbols on OS X
# New Ticket Created by Allison Randal # Please include the string: [perl #50056] # in the subject line of all future correspondence about this issue. # URL: 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 OS X (Tiger). Previously it was only a handful of failing tests, but now it's preventing 'make' from completing, terminating with the following error: -- 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/lib -lparrot -L/Users/allison/projects/svn/parrot/blib/lib -lm -lgmp -lreadline /Users/allison/projects/svn/parrot/src/parrot_config.o /usr/bin/ld: Undefined symbols: _Parrot_set_executable_name collect2: ld returned 1 exit status linking failed current instr.: 'link_file' pc 752 (pbc_to_exe.pir:365) called from Sub 'main' pc 124 (pbc_to_exe.pir:32) make: *** [pbc_to_exe] Error 1 -- Looks like this particular failure was caused by r25020, but it's only a symptom of the wider problem. Allison
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 error: -- 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/lib -lparrot -L/Users/allison/projects/svn/parrot/blib/lib -lm -lgmp -lreadline /Users/allison/projects/svn/parrot/src/parrot_config.o /usr/bin/ld: Undefined symbols: _Parrot_set_executable_name collect2: ld returned 1 exit status linking failed current instr.: 'link_file' pc 752 (pbc_to_exe.pir:365) called from Sub 'main' pc 124 (pbc_to_exe.pir:32) make: *** [pbc_to_exe] Error 1 -- Looks like this particular failure was caused by r25020, but it's only a symptom of the wider problem. Does this happen after a 'make realclean' and recompilation? You in particular know that I have a special dislike for the state of building and linking C code on Mac OS X, being dangerously close to The Best That Unix Had To Offer Circa NeXT 1987... ... but apart from slapping PARROT_API on the symbol, what in the world do we need to do special to tell GCC 4.x on Mac OS X to: 1) hide symbols not explicitly exported 2) actually export symbols when we mark them as exportable I mean, the main reason we hide symbols by default is so that we'll catch what would be compilation errors on Win32 on platforms with GCC 4.x, but if Mac OS X can't handle a bog-standard compilation option, well maybe we should work on getting them the source code to GCC or something. -- c
Re: [perl #50056] [BUG] Undefined symbols on OS X
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 back to trunk and ran 'make realclean', and there it was. You in particular know that I have a special dislike for the state of building and linking C code on Mac OS X, being dangerously close to The Best That Unix Had To Offer Circa NeXT 1987... .. but apart from slapping PARROT_API on the symbol, what in the world do we need to do special to tell GCC 4.x on Mac OS X to: 1) hide symbols not explicitly exported 2) actually export symbols when we mark them as exportable I mean, the main reason we hide symbols by default is so that we'll catch what would be compilation errors on Win32 on platforms with GCC 4.x, but if Mac OS X can't handle a bog-standard compilation option, well maybe we should work on getting them the source code to GCC or something. Maybe I should try compiling on LLVM. ;) Allison
