Bug 219810 - net/lft requires pcap-int.h which has been removed from base r31-May-2017 Mark as broken.
Summary: net/lft requires pcap-int.h which has been removed from base 31-May-2017 Mark...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Babak Farrokhi
Depends on:
Reported: 2017-06-06 02:58 UTC by dewayne
Modified: 2018-01-08 06:28 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (farrokhi)


Note You need to log in before you can comment on or make changes to this bug.
Description dewayne 2017-06-06 02:58:52 UTC
Changes to the base system of FreeBSD11 Pre-release prevents pcap-int.h from being installed, hence disables the build of net/lft. Specifically:

r319279 | delphij | 2017-05-31 15:20:59 +1000 (Wed, 31 May 2017) | 31 lines
Stop installing pcap-int.h, which is the internal interface for libpcap.

Reference:      https://github.com/the-tcpdump-group/libpcap/issues/560
PR:             217221
As this file is no longer installed into /usr/include, the port is unable to be built for all platforms.  

I miss the workaround part of the PR, so here it is
Workaround (very temporary)
cp /usr/src/contrib/libpcap/pcap-int.h /usr/include
Comment 1 dewayne 2017-06-06 05:22:44 UTC
(In reply to dewayne from comment #0)
Oops and as *workaround* also 
cp /usr/src/contrib/libpcap/portability.h /usr/include
Comment 2 Babak Farrokhi freebsd_committer 2017-06-06 09:37:35 UTC
You may want to try the patch from ongoing review: https://reviews.freebsd.org/D11072
Comment 3 dewayne 2017-06-07 00:48:08 UTC
(In reply to Babak Farrokhi from comment #2)
Thanks Babak, that is a good solution as it maintains the port's self-containment.  If the headers were locked this would be ideal, however we never know when libpcap changes (unlikely I know).  I'm sure that the developers of lft assumed that headers would remain available, so unlikelthat they'll reconsider their design and add another level of indirection into their code to somehow get to the material that lft requires.

For the moment I'll copy from the base machine's /usr/src/... into the various build jails. 

When is a header not? When "someone" decides it reveals internals of something... which is the whole point!  I suppose stdio.h reveals internals, so that might be next.  At least for the sake of a consistent paradigm all headers from /usr/src/contrib should be removed from /usr/include - another ridiculous idea! :-/

Thanks for your help with this problem in a timely manner.
Comment 4 Babak Farrokhi freebsd_committer 2017-07-04 07:15:15 UTC
(In reply to dewayne from comment #3)

Could you give this patch [1] a try? It seems the header file was not being used at all. I also fixed another issue that prevented RAW socket from being created.

[1] https://reviews.freebsd.org/D11072
Comment 5 commit-hook freebsd_committer 2017-07-04 09:50:01 UTC
A commit references this bug:

Author: farrokhi
Date: Tue Jul  4 09:49:30 UTC 2017
New revision: 445013
URL: https://svnweb.freebsd.org/changeset/ports/445013

  Unbreak on 11-STABLE and 12-CURRENT

  - Remove reference to unused header file that caused build failure on 11.x+
  - Fix the logic to create RAW sockets appropriately (reported by Andrew Wu)

  PR:		219810
  Reported by:	Andrew Wu <yauhwawu@gmail.com> , dewayne@heuristicsystems.com.au
  Reviewed by:	bapt
  Approved by:	bapt
  Differential Revision:	https://reviews.freebsd.org/D11072

Comment 6 Walter Schwarzenfeld freebsd_triage 2018-01-07 19:02:09 UTC
Forgotten to close?
Comment 7 Babak Farrokhi freebsd_committer 2018-01-08 06:28:02 UTC
(In reply to w.schwarzenfeld from comment #6)
yes. thanks for noting.