pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: devel/ncurses 6.0 hackery at least on DragonFly
On Tue, Aug 18, 2015 at 12:37 AM, Thomas Klausner <tk%giga.or.at@localhost> wrote:
> On Tue, Aug 18, 2015 at 12:13:31AM -0700, David Shao wrote:
>
>> Then git-base failed to build with:
>>
>> SUBDIR templates
>> MSGFMT po/build/locale/zh_CN/LC_MESSAGES/git.mo
>> /usr/pkg/lib/libncurses.so.6: version NCURSES_5.9 required by
>> /usr/pkg/lib/libgettextlib-0.19.4.so not defined
>> Makefile:2051: recipe for target
>> 'po/build/locale/zh_CN/LC_MESSAGES/git.mo' failed
>> gmake: *** [po/build/locale/zh_CN/LC_MESSAGES/git.mo] Error 1
>
> I'm not sure where libgettextlib gets its dependency on libncurses
> from for you.
>
> Due to your email, I've also bumped all packages using
> mk/curses.buildlink3.mk and mk/terminfo.buildlink3.mk, perhaps that
> improves the situation.
>
>> Also gvim failed to start and neither could I create a new Terminal from Xfce4.
>
> Let me know if these are fixed now or what further packages need a
> PKGREVISION bump.
>
> You should be on the safe side if you do a full pbulk. Then all
> packages using ncurses will be rebuilt.
>
>> It's amazing what
>> .include "../../devel/ncurses/buildlink3.mk"
>> can replace. In particular, the days of
>>
>> .include "../../mk/curses.buildlink3.mk"
>> or
>> .include "../../mk/termcap.buildlink3.mk"
>>
>> may be numbered, at least on pkgsrc DragonFly.
>
> I think it's the other way round -- termcap is a smaller dependency
> than curses, so we prefer to include that if curses is not needed, and
> similarly for curses.
> Thomas
Let me ask a basic question: Is it better to use the native ncurses
if at all possible? Many systems these days come with a reasonably
up-to-date ncurses in their base, /usr/lib and /usr/include, including
DragonFly 4.3.
Here's the following disturbing possibility which I seem to have
confirmed using a simple test: When one first builds from pkgsrc, a
package such as
devel/gettext-tools
will be built near the beginning and will use the native ncurses. But
suppose later in the build process some package such as devel/cmake
decides it needs to pull in pkgsrc ncurses.
I suppose a large number of people these days use pre-built pkgsrc
packages. And most who build from pkgsrc manually are probably sane
enough to avoid randomly updating something like gettext-tools. It's
only an obsessive like me who one days updates gettext-tools.
Now when gettext-tools was first built, there was no pkgsrc ncurses on
the system, so it happily picked up the native ncurses. I see this
using ldd on libgettextlib-0.19.4, the linkage is to
libncurses.so.6 => /lib/libncurses.so.6
But if pkgsrc ncurses exists on the system, running in devel/gettext-tools
bmake clean && bmake configure
I can see
./work/.work.log:[*]
/usr/pkgsrc/devel/gettext-tools/work/.wrapper/bin/cc
/usr/pkgsrc/devel/gettext-tools/work/.wrapper/bin/cc -o conftest -g
-I/usr/pkg/include -I/usr/include -I/usr/pkg/include -I/usr/include
-L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib conftest.c
-lintl /usr/pkg/lib/libncurses.so -Wl,-rpath -Wl,/usr/pkg/lib
Now the build system is going out of its way apparently to link in
pkgsrc ncurses. I think this might be coming from one of terminfo.m4
bundled with gettext-tools.
I have the sinking feeling before I even started to build from pkgsrc,
I should have defined in /usr/pkg/etc/mk.conf:
USE_BUILTIN.ncurses=yes
Now to get back native ncurses, I have to go around manually altering
Makefiles to use
.include "../../devel/ncurses/buildlink3.mk"
And even then this is worrying me, that the native ncurses lib might
not be found:
./work/.extract_makevars.mk:BUILDLINK_PREFIX.ncurses= /usr
./work/.extract_makevars.mk:BUILTIN_LIB_FOUND.ncurses= no
./work/.extract_makevars.mk:H_CURSES= /usr/include/ncurses.h
./work/.extract_makevars.mk:H_CURSES1= /usr/include/ncurses.h
./work/.extract_makevars.mk:H_NCURSES= /usr/include/ncurses.h
./work/.extract_makevars.mk:IS_BUILTIN.ncurses= no
./work/.extract_makevars.mk:USE_BUILTIN.ncurses= yes
./work/.configure_makevars.mk:BUILDLINK_PREFIX.ncurses= /usr
./work/.configure_makevars.mk:BUILTIN_LIB_FOUND.ncurses= no
I'm not sure that endless rebuilding is the answer. I wonder if the
answer is to at all costs never allow pkgsrc ncurses to be installed
in the first place, because if one really needs to use it, it needs to
be used everywhere including basic packages like gettext-tools.
Home |
Main Index |
Thread Index |
Old Index