Re: pkg/51728: devel/ncurses renaming of lib{form,menu,panel} should be reverted before next release

[David Holland <dholland-pbugs%netbsd.org@localhost>]

The following reply was made to PR pkg/51728; it has been noted by GNATS.

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/51728: devel/ncurses renaming of lib{form,menu,panel} should
 be reverted before next release
Date: Sun, 25 Dec 2016 19:41:49 +0000

 On Sun, Dec 25, 2016 at 07:25:00PM +0000, David Holland wrote:
  >   > To rename such well-known libraries is imposing on each porter an
  >   > obligation to search through the package to see whether
  >   > lib{form,menu,panel} are used, and if so, to find out how to rename
  >   > these libraries with patches that can NEVER be accepted upstream.
  >  
  >  Nope...
 
 to expand on this (since on reflection I'm not sure how much you may
 know about this stuff so far)
 
  - work/.buildlink/lib should contain links pointing to the correct
 curses, form, panel, etc. libraries.
 
  - the wrappers rewrite all compiler invocations to add
 -L${WKRDIR}/.buildlink/lib.
 
  - either the wrappers should translate -lform to the renamed name, or
 there should be a libform.so in .buildlink/lib that's a link to the
 renamed lib. (If neither of these is the case, the renaming is broken
 and needs to be fixed. Check work/.work.log to see what the wrappers
 do.)
 
  - the wrappers also prune package-supplied -L options like
 -L/wrong/base/dir or -L/usr/local/lib or whatever. Also /usr/pkg/lib.
 
  - therefore, any package that just does -lform -lcurses will get the
 right libraries and (for the most part) will not be able to use the
 wrong libraries.
 
 Packages that use curses but don't include mk/curses.bl3.mk will not
 get the right sausage out. This will not keep them from building on
 systems with curses libraries on the default linker path (typically
 only /usr/lib) because the wrappers can't effectively intercept that.
 Most of these should have been found and fixed already by now,
 though.
 
 Packages that are too smart for their own good and do too-clever
 configure tests instead of just running the compiler like autoconf
 will sometimes find things they aren't supposed to see, draw wrong
 conclusions, and fail. This is probably what's happening with cmake.
 
 To fix this problem properly we need to figure out why it probed
 itself an inconsistent set of assumptions than then failed. Which
 means looking at the logic that probes for CURSES_FORM_LIBRARY and
 figuring out what it did that circumvented the wrappers.
 
 I am assuming CMAKE_USE_SYSTEM_FORM means "don't use some random copy
 of libform that came in the cmake distfile" and should therefore
 always be set to "ON".
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost