[MacPorts] #44647: p5.20-io-tty: fails to build on 10.6
#44647: p5.20-io-tty: fails to build on 10.6 -------------------------+-------------------------------- Reporter: mojca@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: snowleopard | Port: p5.20-io-tty -------------------------+-------------------------------- {{{ /usr/bin/gcc-4.2 -c -pipe -Os -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -fstack- protector -I/opt/local/include -arch x86_64 -O3 -DVERSION=\"1.11\" -DXS_VERSION=\"1.11\" "-I/opt/local/lib/perl5/5.20/darwin-thread-multi- 2level/CORE" -DHAVE_DEV_PTMX -DHAVE_GRANTPT -DHAVE_OPENPTY -DHAVE_POSIX_OPENPT -DHAVE_PTSNAME -DHAVE_SIGACTION -DHAVE_STRLCPY -DHAVE_TERMIOS_H -DHAVE_TTYNAME -DHAVE_UNLOCKPT -DHAVE_UTIL_H Tty.c In file included from Tty.xs:61: /opt/local/lib/perl5/5.20/darwin-thread-multi-2level/CORE/util.h:69: error: redefinition of typedef ‘perl_drand48_t’ /opt/local/lib/perl5/5.20/darwin-thread-multi-2level/CORE/util.h:69: error: previous declaration of ‘perl_drand48_t’ was here make: *** [Tty.o] Error 1 make: Leaving directory `/opt/local/var/macports/build/_opt_mports_dports_perl_p5-io-tty/p5.20-io- tty/work/IO-Tty-1.11' Command failed: cd "/opt/local/var/macports/build/_opt_mports_dports_perl_p5-io-tty/p5.20-io- tty/work/IO-Tty-1.11" && /usr/bin/make -j8 -w all Exit code: 2 }}} One might want to rebuild at least the following ports on 10.6 when the problem gets fixed: * p5.20-ipc-run * p5.20-graphviz * p5.20-module-signature * p5.20-panotools-script * p5.20-dbd-pg -- Ticket URL: <https://trac.macports.org/ticket/44647> MacPorts <http://www.macports.org/> Ports system for OS X
#44647: p5.20-io-tty: fails to build on 10.6 ---------------------------+-------------------------------- Reporter: mojca@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: snowleopard Port: p5.20-io-tty | ---------------------------+-------------------------------- Comment (by ryandesign@…): Please see https://github.com/toddr/IO-Tty/pull/3 -- Ticket URL: <https://trac.macports.org/ticket/44647#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#44647: p5.20-io-tty: fails to build on 10.6 ---------------------------+-------------------------------- Reporter: mojca@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: snowleopard Port: p5.20-io-tty | ---------------------------+-------------------------------- Comment (by mojca@…): Thank you very much for the pointer. I would actually be more inclined towards fixing `util.h` in Perl itself. Looking at this: * http://stackoverflow.com/questions/6526322/why-redefinition-of- typedef-error-with-gcc-4-3-but-not-gcc-4-6 it makes me suspect that the following definitions in `util.h` are not written properly / don't behave well with older compilers: {{{ /* outside the core, perl.h undefs HAS_QUAD if IV isn't 64-bit We can't swap this to HAS_QUAD, because the logic here affects the type of perl_drand48_t below, and that is visible outside of the core. */ #if defined(U64TYPE) && !defined(USING_MSVC6) /* use a faster implementation when quads are available, * but not with VC6 on Windows */ # define PERL_DRAND48_QUAD #endif #ifdef PERL_DRAND48_QUAD /* U64 is only defined under PERL_CORE, but this needs to be visible * elsewhere so the definition of PerlInterpreter is complete. */ typedef U64TYPE perl_drand48_t; #else struct PERL_DRAND48_T { U16 seed[3]; }; typedef struct PERL_DRAND48_T perl_drand48_t; #endif #define PL_RANDOM_STATE_TYPE perl_drand48_t #define Perl_drand48_init(seed) (Perl_drand48_init_r(&PL_random_state, (seed))) #define Perl_drand48() (Perl_drand48_r(&PL_random_state)) }}} but I'm not yet sure how to fix that either. Other than that I don't see any reason not to switch to `PERL_SUBVERSION` etc. But it really makes more sense to me to fix Perl's headers. The bug report for io-tty is here: https://rt.cpan.org/Public/Bug/Display.html?id=96710 -- Ticket URL: <https://trac.macports.org/ticket/44647#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X
#44647: p5.20-io-tty: fails to build on 10.6 ---------------------------+-------------------------------- Reporter: mojca@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: snowleopard Port: p5.20-io-tty | ---------------------------+-------------------------------- Comment (by mojca@…): It might also help to use a different/more recent compiler. -- Ticket URL: <https://trac.macports.org/ticket/44647#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#44647: p5.20-io-tty: fails to build on 10.6 ---------------------------+-------------------------------- Reporter: mojca@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: snowleopard Port: p5.20-io-tty | ---------------------------+-------------------------------- Comment (by ryandesign@…): Replying to [comment:2 mojca@…]:
I would actually be more inclined towards fixing `util.h` in Perl itself. Looking at this: * http://stackoverflow.com/questions/6526322/why-redefinition-of- typedef-error-with-gcc-4-3-but-not-gcc-4-6 it makes me suspect that the following definitions in `util.h` are not written properly / don't behave well with older compilers:
Is there a perl bug report for this then? -- Ticket URL: <https://trac.macports.org/ticket/44647#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#44647: p5.20-io-tty: fails to build on 10.6 ---------------------------+-------------------------------- Reporter: mojca@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: snowleopard Port: p5.20-io-tty | ---------------------------+-------------------------------- Comment (by mojca@…): I didn't submit one yet. I'm always confused by their interface and had problems submitting reports in the past. But in either case we would probably have a better change to get it fixed if we manage to find some patch. -- Ticket URL: <https://trac.macports.org/ticket/44647#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts