tech-pkg archive

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

Re: FireFox 10.0.1 pkg for testing

On 3/10/2012 10:35 PM, Martin Husemann wrote:
So I had a look and there are two problems.

First: the linker does not follow NEEDED entries in shared objects. For
whatever reason (contrary to the documentation) adding the
--copy-dt-needed option did not solve it in my experiments, but just
adding the  required libs past -lnss fixes most unresolved symbols:

   -lnss3 -lplc4 -lplds4 -lnspr4 -lnssutil3

instead of just


The second issue is a bit trickier. If you look at the object generated,
you see:

objdump -t ipc/chromium/process_util_bsd.o|fgrep kvm
0000000000000000         *UND*  0000000000000000 .hidden kvm_open
0000000000000000         *UND*  0000000000000000 .hidden kvm_getprocs
0000000000000000         *UND*  0000000000000000 .hidden kvm_close

Now this of course is plain wrong. The cause is a bug in /usr/include/cdefs.h:

#define     __BEGIN_DECLS   extern "C" {

This needs to explicitly set the visibility, here is the NetBSD variant of

#if defined(__cplusplus)
#define __BEGIN_EXTERN_C        extern "C" {
#  define __BEGIN_PUBLIC_DECLS  \
         _Pragma("GCC visibility push(default)") __BEGIN_EXTERN_C
#define __BEGIN_DECLS           __BEGIN_PUBLIC_DECLS

Since you can not easily fix this for all existing installs out there
without a time machine, I'd suggest you add something similar around
the #include<kvm.h>  for DragonFly in process_util_bsd.cpp.

I am not sure how to best fix the library dependeny issue inside pkgsrc,
but you probably can do that easily. The source patch for the second problem
should be easy, let me know if you want me to handle it.

Thanks Martin,
I hadn't had a chance to look at this yet, but you've done a lot of work here. On the library dependency issue, since this is the new default starting with binutils 2.22, we've been doing exactly this: adding the libraries for direct link. Since the camp is split on whether this is desirable for pkgsrc, I've started only doing it for DragonFly using various techniques such as LDFLAGS.DragonFly, etc.

on the cdefs, is this actually a bug in cdefs or is a failure of libkvm to explicitly export their symbols? (e.g. __dso_public, it think we borrowed that from NetBSD). Without fully understanding the issue, forcing all symbols to be exported by default disables the binutils visibility logic which is supposed to make c++ start faster due to smaller symbol tables, right?


Home | Main Index | Thread Index | Old Index