#57724: py37-zmq @17.1.2: Build failure, can't locate installed zmq
Reporter: SerpentChris | Owner: jrjsmrtn
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Keywords: | Port: py37-zmq
It looks like the project tries to run it's own script to locate the
installed zmq library, and failing that it defaults to a version it has
bundled with it's own source code. I'm building this on a Power Mac G5
running Mac OS X 10.5.8.
Update: I tried downloading the pyzmq source code off github, and
compiling it that way. The problem is that when it tests the installed
library, it compiles a C file into an executable, but when I run the
executable it says "Illegal Instruction" and exits with code 132. I don't
fully understand why it takes two steps to build the executable though.
Here are the lines:
Here is the error and gdb run with the stock version, built with that
$ gdb ./zmq_vers
GNU gdb 6.3.50-20050815 (Apple version gdb-967) (Tue Jul 14 02:15:14 UTC
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
welcome to change it and/or distribute copies of it under certain
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
This GDB was configured as "powerpc-apple-darwin"...Reading symbols for
shared libraries .... done
Starting program: /Users/cunningh/zmq_vers
Reading symbols for shared libraries +++.. done
Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x0008d034 in _mh_dylib_header ()
#0 0x0008d034 in _mh_dylib_header ()
#1 0x000b41e0 in std::_Rb_tree<std::string, std::pair<std::string const,
zmq::own_t* (zmq::session_base_t::*)(zmq::io_thread_t*, bool)>,
std::_Select1st<std::pair<std::string const, zmq::own_t*
(zmq::session_base_t::*)(zmq::io_thread_t*, bool)> >,
std::less<std::string>, std::allocator<std::pair<std::string const,
zmq::own_t* (zmq::session_base_t::*)(zmq::io_thread_t*, bool)> >
>::_M_insert_unique<std::pair<std::string const, zmq::own_t*
(zmq::session_base_t::*)(zmq::io_thread_t*, bool)>*> ()
#2 0x000edbfc in _GLOBAL__sub_I_session_base.cpp ()
#3 0x8fe13834 in
#4 0x8fe0f248 in
#5 0x8fe0f198 in
#6 0x8fe0f36c in
#7 0x8fe03848 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#8 0x8fe08144 in __dyld__ZN4dyld5_mainEPK11mach_headermiPPKcS5_S5_ ()
#9 0x8fe01774 in __dyld__ZN13dyldbootstrap5startEPK11mach_headeriPPKcl ()
#10 0x8fe01048 in __dyld__dyld_start ()
The program is running. Exit anyway? (y or n) y
I have no idea at this moment what is going on to cause this illegal
instruction error when zmq is build with gcc6 in -std=c++11 mode, but
whatever it is goes away when zmq is built with gcc-4.2 in non-c++11 mode.
Now we have to see why that block forcing gcc6 / c++11 for PPC is in the
Portfile in the first place...
Michael -- I don't know the slightest thing about `zmq` -- but I can
confirm that with the block forcing gcc6/c++11 removed, both `zmq` and
`zmq-devel` build and don't crash when running the version test program
I see it was put in a few months ago to fix a build failure noted at that
time. The log is no longer available on the buildbot, so I don't know what
was happening back then, but it seems to be gone (for now .... ).
Suggest we disable the force, and revbump (only the PPC version needs a
revbump, if you want to do it like that).
Interesting. Here's the commit: https://github.com/macports/macports- ports/commit/c0c1c89f851334207b481fcaa58329ac5e8247e1 . Let me test
tomorrow at work (where my PPC box is), but it seems like the ZMQ folks
might have fixed whatever the issue was (regardless of intentionality).
I'd definitely prefer to not require C++11 if it's not required! It -is-
pretty strange that using C++11 results in crashes; that's probably a
OK well it took me more than a day to get to this point ... fighting the
!@#$ internet at my shared workspace. When I remove per Ken's advice and
reinstall zmq (or zmq-devel), then py*-zmq does indeed install cleanly. I
wonder what the difference is in what ZMQ installs when C++11 is forced
versus when it is not ... maybe ports using ZMQ are also required to use
C++11? Anyway, I'll fix up the ZMQ Portfile with this fix shortly.
zmq[-devel]: remove "special building for PPC/PPC64"
+ although ZMQ builds forcing C++11, some dependent ports do not;
+ forcing C++11 is no longer necessary due to code changes from upstream;
+ rev-bump zmq and zmq-devel for possible change.