tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: math/R failing to install
> On Jun 25, 2016, at 12:45 PM, David Holland <dholland-pkgtech%netbsd.org@localhost> wrote:
>
> On Sat, Jun 25, 2016 at 10:26:43AM -0600, Brook Milligan wrote:
>> /usr/pkg/lib/libxcb-shm.so.0.0.0:
>> -lxcb.2 => /usr/X11R7/lib/libxcb.so.2
>> -lXau.7 => /usr/X11R7/lib/libXau.so.7
>> -lgcc_s.1 => /usr/lib/libgcc_s.so.1
>> -lc.12 => /usr/lib/libc.so.12
>> -lXdmcp.7 => /usr/X11R7/lib/libXdmcp.so.7
There is a more general pattern behind the problem I am having. Every library I have installed in /usr/pkg that references libcairo also references the pkgsrc libxcb-shm and the native libxcb. Here is one example (in part):
libpangocairo-1.0.so:
-lcairo.2 => /usr/pkg/lib/libcairo.so.2
-lxcb-shm.0 => /usr/pkg/lib/libxcb-shm.so.0
-lxcb.2 => /usr/X11R7/lib/libxcb.so.2
/usr/pkg/lib/libxcb-shm.so.0 references four undefined symbols:
U xcb_get_reply_fds # defined in /usr/X11R7/lib/libxcb.so.2.0
U xcb_send_request # defined in /usr/X11R7/lib/libxcb.so.1.1 and 2.0
U xcb_send_request_with_fds # not defined in any /usr/X11R7/lib/*.so
U xcb_wait_for_reply # defined in /usr/X11R7/lib/libxcb.so.1.1 and 2.0
Note that all four of these symbols are defined in /usr/pkg/lib/libxcb.so.1.1.0, which is built from the x11/libxcb package. The latter is also the source of the libxcb-shm library, so the two should always match.
Presumably, as long as xcv_send_request_with_fds is not referenced, this works and all the libraries linked this way succeed. However, for me the R configure script is somehow referencing that symbol and failing to link with this combination of libraries. Clearly, it would link fine against the pkgsrc version of libxcb.
This strikes me as a very brittle situation in general, i.e., beyond my immediate problem with R, as it suggests the potential for library inconsistencies to arise, something that could affect anything linking against cairo at least.
Pure speculation (but perhaps helpful to point someone with more clue in a potentially useful direction): I am guessing that this is somehow related to the handling of builtin.mk for libxcb. Even though the package provides both libxcb and libxcb-shm (at least), only the builtin for libxcb is applied so that the pkgsrc version of libxcb-shm is used instead of the native one. Alternatively, could it have to do with the fact that the pkgsrc libxcb is v1.1.0 while the native one is v2.0 (even though the pkgsrc one has more symbols and might be newer)?
Please advise on the solution to this inconsistency.
Thanks a lot.
Cheers,
Brook
Home |
Main Index |
Thread Index |
Old Index