From mojca@macports.org

Dear Developers,

Today I started playing with 5.24.0-RC5 for a future inclusion into
MacPorts, but here's the error I encountered​:
  https://trac.macports.org/ticket/51330

Undefined symbols for architecture x86_64​:
  "_environ", referenced from​:
  _perl_construct in perl.o
  _S_init_postdump_symbols in perl.o
  _Perl_my_setenv in util.o
  _Perl_my_clearenv in util.o
  _Perl_init_i18nl10n in locale.o
ld​: symbol(s) not found for architecture x86_64

I tested on 64-bit Mac OS X 10.7, but I assume the same problem should
be present in other versions of OS X. The build procedure is exactly
the same that worked fine for Perl 5.8-5.22 on all OS X versions.

Configure arguments and the complete build log are available at
  https://trac.macports.org/attachment/ticket/51330/perl5.24-main.log
These are the patches that we use​:
  https://trac.macports.org/browser/trunk/dports/lang/perl5/files/5.24

I will try to build again in a clean environment outside of MacPorts
and compare the results, but I wanted to report the problem as early
as possible.

Mojca

From mojca.miklavec.lists@gmail.com

See also https://rt-archive.perl.org/perl5/Ticket/Display.html?id=126240

The RT System itself - Status changed from 'new' to 'open'

From @jhi

On Sat May 07 03​:56​:11 2016, mojca@​macports.org wrote​:

Dear Developers,

Today I started playing with 5.24.0-RC5 for a future inclusion into
MacPorts, but here's the error I encountered​:
https://trac.macports.org/ticket/51330

Undefined symbols for architecture x86_64​:
"_environ", referenced from​:
_perl_construct in perl.o
_S_init_postdump_symbols in perl.o
_Perl_my_setenv in util.o
_Perl_my_clearenv in util.o
_Perl_init_i18nl10n in locale.o
ld​: symbol(s) not found for architecture x86_64

I tested on 64-bit Mac OS X 10.7, but I assume the same problem should
be present in other versions of OS X. The build procedure is exactly
the same that worked fine for Perl 5.8-5.22 on all OS X versions.

Configure arguments and the complete build log are available at
https://trac.macports.org/attachment/ticket/51330/perl5.24-main.log
These are the patches that we use​:
https://trac.macports.org/browser/trunk/dports/lang/perl5/files/5.24

I will try to build again in a clean environment outside of MacPorts
and compare the results, but I wanted to report the problem as early
as possible.

FWIW​: in El Capitan, using your env and Configure invocation from the macports build log, the RC5 [1] builds fine (well, one problem, see [2]), certainly gets past linking the miniperl and perl, and starts building the extensions.

[1] bleadperl as of http​://perl5.git.perl.org/perl.git/commit/4f8325bacaec9fddb2bc901248c77835e53720ed

[2] The one problem, unrelated to not-building as such, I think​: it seems that macports strips the -DPERL_DARWIN flag. The flag really is needed for at least Time​::HiRes as it is in the RC5. If it is not there, the OS X emulation of clock_gettime() etc. is not picked up, and the T​::H compilation fails. Whether that's the right flag to be needing is another discussion, but it certainly needed now.

From @jhi

On Sat May 07 06​:12​:25 2016, jhi wrote​:

On Sat May 07 03​:56​:11 2016, mojca@​macports.org wrote​:

Dear Developers,

Today I started playing with 5.24.0-RC5 for a future inclusion into
MacPorts, but here's the error I encountered​:
https://trac.macports.org/ticket/51330

Undefined symbols for architecture x86_64​:
"_environ", referenced from​:
_perl_construct in perl.o
_S_init_postdump_symbols in perl.o
_Perl_my_setenv in util.o
_Perl_my_clearenv in util.o
_Perl_init_i18nl10n in locale.o
ld​: symbol(s) not found for architecture x86_64

I tested on 64-bit Mac OS X 10.7, but I assume the same problem
should
be present in other versions of OS X. The build procedure is exactly
the same that worked fine for Perl 5.8-5.22 on all OS X versions.

Configure arguments and the complete build log are available at
https://trac.macports.org/attachment/ticket/51330/perl5.24-
main.log
These are the patches that we use​:
https://trac.macports.org/browser/trunk/dports/lang/perl5/files/5.24

I will try to build again in a clean environment outside of MacPorts
and compare the results, but I wanted to report the problem as early
as possible.

FWIW​: in El Capitan, using your env and Configure invocation from the
macports build log, the RC5 [1] builds fine (well, one problem, see
[2]), certainly gets past linking the miniperl and perl, and starts
building the extensions.

[1] bleadperl as of
http​://perl5.git.perl.org/perl.git/commit/4f8325bacaec9fddb2bc901248c77835e53720ed

[2] The one problem, unrelated to not-building as such, I think​: it
seems that macports strips the -DPERL_DARWIN flag. The flag really is
needed for at least Time​::HiRes as it is in the RC5. If it is not
there, the OS X emulation of clock_gettime() etc. is not picked up,
and the T​::H compilation fails. Whether that's the right flag to be
needing is another discussion, but it certainly needed now.

Hmm, something still is definitely broken in El Capitan with your build setup. Everything builds, and "make minitest" passes, but "make test" doesn't fare that well​:

...
Running Mkbootstrap for threads​::shared ()
chmod 644 "shared.bs"
DYLD_LIBRARY_PATH=/Users/jhi/perl ./perl -Ilib -f pod/buildtoc -q
cd t && (rm -f perl; /bin/ln -s ../perl perl)
DYLD_LIBRARY_PATH=/Users/jhi/perl ./runtests choose
dyld​: Library not loaded​: /opt/local/lib/perl5/5.24.0/darwin-thread-multi-2level/CORE/libperl.dylib
  Referenced from​: /Users/jhi/perl/t/./perl
  Reason​: image not found
./runtests​: line 70​: 7494 Trace/BPT trap​: 5 ./perl $TESTFILE $TEST_ARGS $TEST_FILES < /dev/tty
make​: *** [test] Error 133

I'm suspecting the versioning change 53d1d41 is relevant.

For the environ failure for you (which I am not seeing in 10.11) see e396210.

From @craigberry

On Sat, May 7, 2016 at 8​:12 AM, Jarkko Hietaniemi via RT
<perlbug-followup@​perl.org> wrote​:

On Sat May 07 03​:56​:11 2016, mojca@​macports.org wrote​:

Dear Developers,

Today I started playing with 5.24.0-RC5 for a future inclusion into
MacPorts, but here's the error I encountered​:
https://trac.macports.org/ticket/51330

Undefined symbols for architecture x86_64​:
"_environ", referenced from​:
_perl_construct in perl.o
_S_init_postdump_symbols in perl.o
_Perl_my_setenv in util.o
_Perl_my_clearenv in util.o
_Perl_init_i18nl10n in locale.o
ld​: symbol(s) not found for architecture x86_64

I tested on 64-bit Mac OS X 10.7, but I assume the same problem should
be present in other versions of OS X. The build procedure is exactly
the same that worked fine for Perl 5.8-5.22 on all OS X versions.

Configure arguments and the complete build log are available at
https://trac.macports.org/attachment/ticket/51330/perl5.24-main.log
These are the patches that we use​:
https://trac.macports.org/browser/trunk/dports/lang/perl5/files/5.24

I will try to build again in a clean environment outside of MacPorts
and compare the results, but I wanted to report the problem as early
as possible.

FWIW​: in El Capitan, using your env and Configure invocation from the macports build log, the RC5 [1] builds fine (well, one problem, see [2]), certainly gets past linking the miniperl and perl, and starts building the extensions.

[1] bleadperl as of http​://perl5.git.perl.org/perl.git/commit/4f8325bacaec9fddb2bc901248c77835e53720ed

[2] The one problem, unrelated to not-building as such, I think​: it seems that macports strips the -DPERL_DARWIN flag.

Actually the lack of -DPERL_DARWIN will cause a problem in
Perl_my_setenv() as well. See
12ffbb1.

From mojca.miklavec.lists@gmail.com

My emails don't show up here for some reason, but it seems that I found the culprit. MacPorts doesn't strip any -DPERL_DARWIN away. The problem is that it adds -Dccflags="$CFLAGS" and that seems to overwrite any ccflags that are added by Perl's Configure script and needed for a successful compilation.

I was told that I should use -Accflags instead of -Dccflags and after removing -Dccflags the compilation succeeds.

The tests still fail (https://rt-archive.perl.org/perl5/Ticket/Display.html?id=128095), but that's a different issue altogether. This particular issue seems to be resolved after removing -Dccflags. (I'm not sure whether this is a bug or a feature though. More like you consider this a feature given that an alternative flag exists?)

From mojca@macports.org

On 7 May 2016 at 15​:12, Jarkko Hietaniemi via RT wrote​:

[2] The one problem, unrelated to not-building as such, I think​: it seems that macports strips the -DPERL_DARWIN flag. The flag really is needed for at least Time​::HiRes as it is in the RC5. If it is not there, the OS X emulation of clock_gettime() etc. is not picked up, and the T​::H compilation fails. Whether that's the right flag to be needing is another discussion, but it certainly needed now.

MacPorts doesn't strip -DPERL_DARWIN or at least I didn't find any
traces of explicitly stripping it anywhere.

What it does though is running Configure with -Dccflags="$CFLAGS" and
maybe that overwrites everything else. How should I properly pass
CFLAGS to Perl's configure without overwriting anything?

Thank you,
  Mojca

From mojca@macports.org

What it does though is running Configure with -Dccflags="$CFLAGS" and
maybe that overwrites everything else. How should I properly pass
CFLAGS to Perl's configure without overwriting anything?

Can you please try to build Perl with -Dccflags=""? I'm curious
whether the problems I'm experiencing are reproducible on your setup
if you do that.

Commit e396210 seems to be fixing
ccflags and maybe that's another example of the same underlying
problem.

Thank you,
  Mojca

From @tonycoz

On Sun May 08 19​:31​:00 2016, mojca@​macports.org wrote​:

What it does though is running Configure with -Dccflags="$CFLAGS" and
maybe that overwrites everything else. How should I properly pass
CFLAGS to Perl's configure without overwriting anything?

Can you please try to build Perl with -Dccflags=""? I'm curious
whether the problems I'm experiencing are reproducible on your setup
if you do that.

Commit e396210 seems to be fixing
ccflags and maybe that's another example of the same underlying
problem.

https://trac.macports.org/ticket/51330 is closed - can this ticket be closed?

Tony

From mojca.miklavec.lists@gmail.com

Dne Pon 16 Maj 2016 18​:05​:23 je tonyc napisal​:

https://trac.macports.org/ticket/51330 is closed - can this ticket be
closed?

I closed it after finding the "workaround" and switched to -Accflags rather than -Dccflags. Perl 5.22 still worked with -Dccflags and it seems that it properly added -DPERL_DARWIN even if I used -Dccflags.

Then again other perl users/developers told me that one should not use -Dccflags at all, so I'm not sure if you consider this to be a bug or a misuse of flags. I would say that it would probably be nice to get it working either way and I'm willing to dig a bit deeper for that (perhaps do some bi-section on history), but ultimately it should be you giving us the directions and the final decision. If you want me to dig a bit further, let me know.

From @tonycoz

On Tue, 17 May 2016 02​:49​:06 -0700, mojca.miklavec.lists@​gmail.com wrote​:

Dne Pon 16 Maj 2016 18​:05​:23 je tonyc napisal​:

https://trac.macports.org/ticket/51330 is closed - can this ticket be
closed?

I closed it after finding the "workaround" and switched to -Accflags
rather than -Dccflags. Perl 5.22 still worked with -Dccflags and it
seems that it properly added -DPERL_DARWIN even if I used -Dccflags.

I tried a Configure​:

  ./Configure -des -Dusedevel -Dccflags='-mmacosx-version-min=10.12 -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -DPERL_USE_SAFE_PUTENV'

but the resulting config didn't have -DPERL_DARWIN​:

  pallas​:perl tony$ grep '^ccflags=' config.sh
  ccflags='-mmacosx-version-min=10.12 -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -DPERL_USE_SAFE_PUTENV -I/usr/local/include'

Then again other perl users/developers told me that one should not use
-Dccflags at all, so I'm not sure if you consider this to be a bug or
a misuse of flags. I would say that it would probably be nice to get
it working either way and I'm willing to dig a bit deeper for that
(perhaps do some bi-section on history), but ultimately it should be
you giving us the directions and the final decision. If you want me to
dig a bit further, let me know.

-D reapplies it's values are hints have been processed, so hints are effectively ignored for that value.

If you supply -Dccflags that aren't enough to build perl correctly, then
it's going to fail and it's your bug not ours.

-Accflags is lot safer and less likely to interfere with perl's configuration/hints processing, but an inappropriate option can still break the build.

Tony

@tonycoz - Status changed from 'open' to 'stalled'

@tonycoz - Status changed from 'stalled' to 'rejected'