Current-Users archive

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

Re: Failure to build "current" emacs from pkgsrc on current

Hi Greg,

Greg Troxel wrote:

Yes, but it can hit an error and exit without finishing.

So I would run it again and see if it reports that there's nothing to

I did re-run it and it breaks out in the same place!

I don't have much useful advice, other than to start using nm or objdump
on the libraries in question and trace which symbols are defined where.

On netbsd-7 amd64, 2018Q3:

nm -u /usr/pkg/lib/|egrep glx
U epoxy_glx_version
U epoxy_has_glx_extension

$ nm -u /usr/pkg/lib/|egrep glx
                 U epoxy_glx_version
                 U epoxy_has_glx
                 U epoxy_has_glx_extension

But I'm not really sure epoxy is.

disc$ pkg_info | grep epoxy
libepoxy-1.4.3      Library for OpenGL function pointer management

that looks like you got an in-progress addition and the usual python
default vs 36/37 pkg_chk issue.  not really concerning.

Ok, I'll hope it will go away when pkg_rolling-replace finishes.

My only other suggestions are

1) to make sure that you have rebuilt *everything* after any change from
X11_TYPE from native to/from modular (via "pkg_admin set rebuild-yes

2) to make sure you have no old headers that don't belong, in
/usr/include, /usr/X11R*/include, or /usr/pkg/include.  Use find with
ctime to find .h files not written during update, and pkg_admin check to
look at file checksums vs installed, and then find /usr/pkg -atime +7 to
find files not read by pkg_admin check and investigate.

something that did not upgrade during system update? hmm here I don't follow you exactly what to find though.

I ill attempt cleaning and reinstalling epoxy and gdk.


Home | Main Index | Thread Index | Old Index