zmq +pgm fails to build on 10.8.2

[kyle.tarplee@…]

XCode 4.5.1 it configures but does not build. The log is attached.

The errors look like

:info:build In file included from list.c:22:
:info:build In file included from ./include/impl/framework.h:66:
:info:build In file included from ./include/impl/notify.h:46:
:info:build In file included from ./include/impl/sockaddr.h:38:
:info:build ./include/pgm/in.h:33:8: error: redefinition of 'group_req'
:info:build struct group_req
:info:build        ^
:info:build /usr/include/netinet/in.h:536:8: note: previous definition is here
:info:build struct group_req {
:info:build        ^
:info:build In file included from list.c:22:

[kyle.tarplee@…]

Looks like the version of pgm that comes with zmq 2.2 is bad. You need to replace it like so:

We need a Portfile that does something like this:

wget http://download.zeromq.org/zeromq-2.2.0.tar.gz
tar -xvf zeromq-2.2.0.tar.gz 
cd zeromq-2.2.0/
cd foreign/openpgm/
wget http://openpgm.googlecode.com/files/libpgm-5.2.121~dfsg.tar.gz
cd ../..
./configure --with-pgm=libpgm-5.2.121~dfsg
make -j8
sudo make install

[kyle.tarplee@…]

It also fails with zmq 3.2 with the same error. The error is in PGM so that makes sense. I have tested the above fix to upgrade pgm to 5.2.121 with zmq 3.2 and it works.

[ryandesign (Ryan Carsten Schmidt)]

It looks like zmq has the ability to use an external installation of pgm. So maybe we should make a port for pgm, and then make the zmq port(s) use that.

[kyle.tarplee@…]

That is the way Debian does it. They have a zmq package that depends on a PGM package. PGM is actually a nice library that people might want to use by itself.

[kyle.tarplee@…]

I have tried to use zmq with PGM and it is rather buggy on the mac. I have two ZMQ tickets related to this: LIBZMQ-454, LIBZMQ455. Looks like they will fix the PGM support soon. I think it is still a good idea to have a separate PGM port.

[merijn (Merijn Verstraaten)]

Replying to kyle.tarplee@…:

I have tried to use zmq with PGM and it is rather buggy on the mac. I have two ZMQ tickets related to this: LIBZMQ-454, LIBZMQ455. Looks like they will fix the PGM support soon. I think it is still a good idea to have a separate PGM port.

I had noticed PGM support using the PGM shipped with ZMQ was buggy, but due to the fact I saw multiple tickets for it on the ZMQ tracker I was planning to wait until they update PGM. I don't personally use PGM, so I'm a poor candidate for maintaining a port for it, but if you (or someone else) is willing to get a PGM port working I wouldn't mind making sure ZMQ compiles with it.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #43548.

I see zmq 4.0.4 is out; we should check if that helps.

[cooljeanius (Eric Gallager)]

on 10.6 there is a different issue with zmq's +pgm variant: the build process keeps hanging on a libtool lock, saying: "glibtool: link: Waiting for libpgm_noinst.a.lock to be removed" forever...

[cooljeanius (Eric Gallager)]

Cc Me!

[posita (Matt Bogosian)]

on 10.6 there is a different issue with zmq's +pgm variant: the build process keeps hanging on a libtool lock, saying: "glibtool: link: Waiting for libpgm_noinst.a.lock to be removed" forever...

I found these:

• ​https://lists.gnu.org/archive/html/bug-libtool/2013-06/msg00001.html
• ​https://lists.gnu.org/archive/html/bug-libtool/2003-02/msg00010.html

If I add configure.compiler macports-gcc-4.x to the Portfile, I still get the same error, so it looks like a libtool issue, not a compiler issue.

[posita (Matt Bogosian)]

Update: It looks like the MacPorts' libtool is the offender. If I comment out the line:

#build.args          LIBTOOL=${prefix}/bin/glibtool

Then zmq-devel@4.0.5 +pgm will build without complaint.

[posita (Matt Bogosian)]

What I would suggest is if that build.args line is really necessary for previous versions, move it into the 3.2.x and 2.2.x subsections. That should allow folks to at least build 4.0.x (and hopefully 4.1.x once it's released).

Further, I would migrate (default) dependencies to zmq-devel where possible. For example, in python/py-zmq/Portfile, I would change:

depends_lib-append     path:lib/libzmq.dylib:zmq

To:

depends_lib-append     path:lib/libzmq.dylib:zmq-devel

Similar adjustments might be appropriate in:

• databases/groonga/Portfile
• devel/cppzmq/Portfile
• devel/czmq/Portfile
• perl/p5-zeromq/Portfile
• www/mongrel2/Portfile

I think that's a comprehensive list as of this post.

[posita (Matt Bogosian)]

While I don't think the earlier problem has gone away, it seems to be masked by a more recent issue, namely a missing openpgm (see the main-pgm-no-longer-found.log attachment).

[posita (Matt Bogosian)]

Possible dup: #47810.

[michaelld (Michael Dickens)]

zmq and zmq-devel are currently at version 4.1.3. Is this still an issue really? I don't see it on my 10.8, 10.9, or 10.10 boot disks. Please do the following for more/better testing:

sudo port clean zmq zmq-devel
sudo port selfupdate

then try upgrading or installing zmq or zmq-devel and see if that works. There is not +pgm variant as far as I can tell; maybe that's a dependency variant?

[michaelld (Michael Dickens)]

Cc Me!

[posita (Matt Bogosian)]

zmq and zmq-devel are currently at version 4.1.3. Is this still an issue really?

It looks like zmq-devel has been replaced by zmq, which now builds fine, but no longer provides the +pgm variant (as you noted).

There is not +pgm variant as far as I can tell; maybe that's a dependency variant?

There used to be. It provides multicast support to ZeroMQ (via OpenPGM), but it requires --with-pgm to be used with configure (see <​http://zeromq.org/area:faq> and <​http://zeromq.org/area:download#toc11>. If the +pgm variant has recently gone away, then it sounds like support for multicast is being abandoned for the MacPorts build of ZeroMQ?

Perhaps that is a separate issue? If so, it sounds like both this and #47810 can be closed.

[michaelld (Michael Dickens)]

Because zmq and zmq-devel no longer contain +pgm, I'm closing this ticket as "fixed" because the offending code was disabled. If some day a developer wants to add this variant, s/he will likely need to address this ticket.