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]
