Opened 13 years ago
Closed 13 years ago
#30511 closed defect (fixed)
ngrep fails to build
Reported by: | davidfavor (David Favor) | Owned by: | grace@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.0.0 |
Keywords: | Cc: | fracai, analogue@…, pipeface@… | |
Port: | ngrep |
Description
Log attached.
Attachments (2)
Change History (11)
Changed 13 years ago by davidfavor (David Favor)
comment:1 Changed 13 years ago by mf2k (Frank Schima)
Owner: | changed from macports-tickets@… to grace@… |
---|
comment:2 Changed 13 years ago by fracai
comment:5 Changed 13 years ago by fracai
OK, this is a bug in the ngrep Makefile.in.
As described in [this http://www.mail-archive.com/bug-make@gnu.org/msg00102.html thread], MAKEFLAGS should not be passed recursively to calls to 'make' within the Makefile. Line 66 of Makefile.in contains such an error. Removing the "$(MAKEFLAGS)" bit from that line allows ngrep to build with "make -j2 -w all".
A reinplace should be enough to strip that out prior to calling configure.
I think the following should handle it.
pre-configure { reinplace s|\$(MAKE) \$(MAKEFLAGS)|$(MAKE)| ${worksrcpath}/Makefile.in }
Changed 13 years ago by fracai
Attachment: | Portfile.diff added |
---|
Update to correct MAKECFLAGS prior to configure.
comment:7 Changed 13 years ago by fracai
I've attached a patch which updates the Portfile to correct the MAKECFLAGS issue. It also disables universal building as that seems to be broken. And bumps the revision for good measure (I'm not sure if this is necessary or not).
comment:8 Changed 13 years ago by fracai
This is corrected by changeset r83135.
It's still failing to build +universal for me under Lion though. I'll open a ticket later today.
comment:9 Changed 13 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Universal fixed in r92800.
I'm not sure if there's a deeper underlying cause, but it seems to be related to the "make" being performed as "make -j2 -w all". If you drop the "-w" the build proceeds without issue. The flag is being interpreted somewhere as a build target named "w" instead of as an argument to make.
At least in my case, I also had to disable the universal build. i386 wasn't happy, but x86_64 was.