New Ticket     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #17516 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

netpbm: parallel build fails

Reported by: ryandesign@… Owned by: mas@…
Priority: Normal Milestone:
Component: ports Version: 1.8.0
Keywords: Cc: mcalhoun@…, mas@…
Port: netpbm

Description

With netpbm 10.26.58 and MacPorts trunk (@42849) on Mac OS X 10.4.11 Intel, the parallel build now fails:

--->  Fetching netpbm
--->  Verifying checksum(s) for netpbm
--->  Extracting netpbm
--->  Applying patches to netpbm
--->  Configuring netpbm
--->  Building netpbm
Error: Target org.macports.build returned: shell command " cd "/mp/var/macports/build/_Users_rschmidt_macports_dports_graphics_netpbm/work/netpbm-10.26.58" && nice -n 10 gnumake -j2  messages=yes " returned error 2
Command output: rm -f nstring.h
rm -f mallocvar.h
ln -s /mp/var/macports/build/_Users_rschmidt_macports_dports_graphics_netpbm/work/netpbm-10.26.58/lib/util/nstring.h nstring.h
ln -s /mp/var/macports/build/_Users_rschmidt_macports_dports_graphics_netpbm/work/netpbm-10.26.58/lib/util/mallocvar.h mallocvar.h
gnumake -C /mp/var/macports/build/_Users_rschmidt_macports_dports_graphics_netpbm/work/netpbm-10.26.58/lib/ -f /mp/var/macports/build/_Users_rschmidt_macports_dports_graphics_netpbm/work/netpbm-10.26.58/lib/Makefile \
    SRCDIR=/mp/var/macports/build/_Users_rschmidt_macports_dports_graphics_netpbm/work/netpbm-10.26.58 BUILDDIR=/mp/var/macports/build/_Users_rschmidt_macports_dports_graphics_netpbm/work/netpbm-10.26.58 libnetpbm.dylib 
gnumake -C /mp/var/macports/build/_Users_rschmidt_macports_dports_graphics_netpbm/work/netpbm-10.26.58/buildtools/ -f /mp/var/macports/build/_Users_rschmidt_macports_dports_graphics_netpbm/work/netpbm-10.26.58/buildtools/Makefile \
    SRCDIR=/mp/var/macports/build/_Users_rschmidt_macports_dports_graphics_netpbm/work/netpbm-10.26.58 BUILDDIR=/mp/var/macports/build/_Users_rschmidt_macports_dports_graphics_netpbm/work/netpbm-10.26.58 libopt 
/usr/bin/gcc-4.0 -c -I/mp/var/macports/build/_Users_rschmidt_macports_dports_graphics_netpbm/work/netpbm-10.26.58/lib -I. -DNDEBUG -I/mp/include -O3 -fno-common \
    -o libpm.o libpm.c
/usr/bin/gcc-4.0 -c -I/mp/include -O3 -o libopt.o \
-DSHLIBPREFIXLIST="\"lib\"" \
            \
        libopt.c
In file included from pm.h:16,
                 from libpm.c:42:
pm_config.h:487: error: redefinition of typedef 'uint32n'
pm_config.h:178: error: previous declaration of 'uint32n' was here
pm_config.h:488: error: redefinition of typedef 'int32n'
pm_config.h:179: error: previous declaration of 'int32n' was here
In file included from pm.h:16,
                 from libpm.c:42:
pm_config.h:623: error: redefinition of typedef 'pm_filepos'
pm_config.h:314: error: previous declaration of 'pm_filepos' was here
gnumake[3]: *** [libpm.o] Error 1
gnumake[2]: *** [/mp/var/macports/build/_Users_rschmidt_macports_dports_graphics_netpbm/work/netpbm-10.26.58/lib/libnetpbm.dylib] Error 2
gnumake[2]: *** Waiting for unfinished jobs....
/usr/bin/gcc-4.0 -o libopt -L/mp/lib libopt.o
gnumake[1]: *** [pgm/all] Error 2
gnumake: *** [converter/all] Error 2

Error: Unable to upgrade port: 1

It succeeds if I turn off the parallel build.

Attachments

r733.diff Download (1.2 KB) - added by ryandesign@… 3 years ago.

Change History

Changed 3 years ago by mas@…

  • cc mcalhoun@…, mas@… added

Did we not see this problem a few months ago? It seems mcalhoun enabled parallel build again yesterday.

For the record, it works on my 10.5.5 machine.

I'm disabling parallel build for the time being (r43078) and adding a note about the problem to the Portfile.

Both of you, feedback on how to handle the problem would be appreciated. Personally, I don't think MacPorts is all too resource observant, so we could probably live with parallel build turned off. It's better to have a working Portfile than to have a fast one that only works for some people.

Changed 3 years ago by blb@…

This brings up the question, how do people try to verify parallel is valid? The few times I've done so I usually try building the port several times, since race conditions are a bitch. Even then, you may not catch the issue, or it could be platform or OS version dependent...

Changed 3 years ago by mcalhoun@…

While searching through the history of netpbm to see why parallel build was turned off in the first place,
I was unable to reproduce the error in #16560.
I assumed it had been fixed in one of the subsequent version updates.
It now seems to be Tiger specific.

Testing is a problem.
I would venture to guess that most of use only have one OS version to test on.
For netpbm, at least, we have documentation that parallel_build has historically been a problem on Tiger.

Unfortunately, I have not useful suggestions on how this situation could be improved.

Changed 3 years ago by mcalhoun@…

Since netpbm no longer tries to parallel build, can this ticket be closed?

Changed 3 years ago by mcalhoun@…

  • status changed from new to closed
  • resolution set to fixed

Changed 3 years ago by ryandesign@…

I informed netpbm's author, Bryan Henderson, of the problem again.

Changed 3 years ago by ryandesign@…

Changed 3 years ago by ryandesign@…

Bryan explained that he had fixed the problem in his "Stable", "Advanced" and "Development" branches, but not in the "Super Stable" branch, which is the one the MacPorts netpbm port seems to be following, perhaps because "Super Stable" is the only branch for which netpbm releases source tarballs; the other branches are available only from their Subversion repository.

Sorry, I must not have realized you were using the Super Stable (10.26)
series.  I fixed the parallel make only in Stable, Advanced, and Development.
I don't think this change is a good idea in Super Stable because a) the make
files are rather different there; b) there probably is other work that would
have to be done to make parallel make truly work; and c) parallel make adds
little value.

But if you want to stay with 10.26 and have parallel make, you could try
applying the same change locally.  It's Subversion Revision 733 of 'trunk',
which is this:

He then provided a diff of his revision 733, which I've attached here. We can either try to apply that and see if it works (he thinks it might not), or we can just leave parallel building off until the Stable branch becomes the Super Stable branch. Or we can try to switch the port to use the Stable branch now.

Changed 3 years ago by ryandesign@…

r45211: added note to portfile about the situation

Changed 3 years ago by anonymous

  • milestone Port Bugs deleted

Milestone Port Bugs deleted

Note: See TracTickets for help on using tickets.