[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

libtool pkgsrc DragonFly base ncurses made private

From: David Shao
Subject: libtool pkgsrc DragonFly base ncurses made private
Date: Fri, 19 Feb 2016 19:51:59 -0800

Recently DragonFly BSD 4.5-DEVELOPMENT moved base ncurses libraries to
a private directory, so that ports frameworks should use their own
ncurses.  I have had no problems building against DragonFly's native
supported dports framework; however, there seems a problem using the
previous but now unsupported pkgsrc framework.

Other frameworks seem to support pkgconfig, but, I believe due to
pkgsrc not wanting conflicts with NetBSD's native xorg, pkgsrc
actively impedes the use of pkgconfig in preference to pkgsrc's
buildlink.  Other frameworks also seem to not use libtool to install
whereas pkgsrc does for ncurses.

The problem is that the libdir field in the resulting pkgsrc
libncurses.la on recent DragonFly alone draws in the build directory
from DESTDIR in addition to the desired /usr/pkg/lib.

It appears to me that what is happening is that at least one source
file in the ncurses subdirectory is being regenerated in the second
install pass, leading to the wrong DESTDIR being appended to
libncurses.la libdir.  In the initial pass to make the object files,
the DESTDIR of "" is what is desired for libdir:

gmake[1]: Leaving directory '/usr/pkgsrc/devel/ncurses/work/ncurses-6.0/include'
cd ncurses && /usr/pkg/bin/gmake DESTDIR="" RPATH_LIST="/usr/pkg/lib" all
gmake[1]: Entering directory
/usr/bin/awk -f ./tinfo/MKcodes.awk bigstrings=1 ./../include/Caps >codes.c

However on recent DragonFly during the installation pass some source
files are generated again, and this time a DESTDIR wrong for libdir is

gmake[1]: Leaving directory '/usr/pkgsrc/devel/ncurses/work/ncurses-6.0/include'
cd ncurses && /usr/pkg/bin/gmake
RPATH_LIST="/usr/pkg/lib" install
gmake[1]: Entering directory
mkdir -p /usr/pkgsrc/devel/ncurses/work/.destdir/usr/pkg/lib
/bin/sh -e ./tinfo/MKcaptab.sh /usr/bin/awk 1 ./tinfo/MKcaptab.awk
./../include/Caps > comp_captab.c
libtool --tag=CC --silent --mode=compile cc -DHAVE_CONFIG_H -I.
-I../include -P  -D_BSD_TYPES -D__BSD_VISIBLE
-D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -DNDEBUG -g  --param
max-inline-insns-single=1200 -c ../ncurses/comp_captab.c -o

As a workaround the patch below simply adds another pass into the
ncurses subdirectory right before the c++ subdirectory is processed.
This fixes the problem on recent DragonFly using pkgsrc and seems to
do no harm on FreeBSD 11-current amd64, FreeBSD 10-2-release, NetBSD
7.99.26 amd64 native xorg, and NetBSD 7.99.26 amd64 modular xorg.

However I do not recommend this patch unless there is a general
problem with systems without public base ncurses trying to install
ncurses with libtool.  I am a mere user representing no one, and
pkgsrc is no longer the officially supported ports framework on
DragonFly.  The officially supported framework dports seems to work
just fine without this patch.

This patch is against the original ncurses 6.0.  Note there should be
a tab before echo since that line is eventually written into a

--- aclocal.m4.orig     2015-08-06 00:46:34.000000000 +0000
+++ aclocal.m4

@@ -3589,6 +3592,10 @@ CF_EOF

+       if test "$cf_dir" == "c++" ; then
+               echo '  cd ncurses && ${MAKE} ${TOP_MFLAGS} [$]@' >>Makefile
+       fi
        echo '  cd '$cf_dir' && ${MAKE} ${TOP_MFLAGS} [$]@' >>Makefile

reply via email to

[Prev in Thread] Current Thread [Next in Thread]