RE: Problems building world with 9.0 RC3 [SOLVED]

2012-01-10 Thread Patrick Mahan
-Original Message-
From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd-
questi...@freebsd.org] On Behalf Of Patrick Mahan
Sent: Monday, January 09, 2012 4:28 PM
To: freebsd-questions@freebsd.org
Subject: Problems building world with 9.0 RC3

All,

I am having an issue with getting buildworld to work for me.  It is failing
while building zfs -

cc -DADARA_OS  -
I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/contrib
/opensolaris/lib/libzpool/common -
I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/compat/
opensolaris/include -
I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/compat/
opensolaris/lib/libumem -
I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../sys/cddl/com
pat/opensolaris -
I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/contrib
/opensolaris/head -
I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/contrib
/opensolaris/lib/libuutil/common -
I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/contrib
/opensolaris/lib/libzfs/common -
I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/contrib
/opensolaris/lib/libumem/common -
I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/contrib
/opensolaris/lib/libnvpair -
I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../sys/cddl/con
trib/opensolaris/uts/common -
I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../sys/cddl/con
trib/opensolaris/uts/common/fs/zfs -
I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../sys/cddl/con
trib/opensolaris/uts/common/sys -
I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../sys/cddl/con
trib/opensolaris/common/zfs -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-
protector -Wno-pointer-sign -Wno-unknown-pragmas  -o zfs zfs_main.o
zfs_iter.o -lbsdxml -lgeom -lm -lnvpair -lsbuf -lumem -lutil -luutil -lzfs
/lib/libthr.so.3: undefined reference to `__pselect@FBSDprivate_1.0'
/data/pmahan/devel/pm_ipr9.0/ipr9.0/amd64/obj/data/pmahan/devel/pm_ipr9.0/ip
r9.0/src/tmp/usr/lib/libzfs.so: undefined reference to `openat@FBSD_1.2'

Now, when I take a look at libpthr.so.3 I for '__pselect' I find -

pmahan@libthr 90  readelf --symbols libthr.so.3 | grep __pselect
   455: c000   120 FUNCGLOBAL DEFAULT   11
___pselect@@FBSDprivate_1.0
   624: c000   120 FUNCGLOBAL DEFAULT   11 ___pselect

So I see the symbol there but with a double @ not a single.  I don't see
any errors generated
when libthr.so.3 is being built so I'm a bit of a loss to understand this.
I saw in my googling that
the wacky symbol naming was introduced sometime in 8.x, but I I couldn't
find anything explaining
the symbol generation.

So I am looking for pointers on how to track this one down.  Is this a
compiler issue?


I figured this out today, thanks to a colleague who was building just fine.
It turns out that I had LD_LIBRARY_PATH set in my environment (no particular
reason, just left over environmental stuff from years of abuse).

It pointed to '/lib:/usr/lib:/usr/local/lib'

So I'm guessing the it was picking up a library outside of the buildworld
sandbox.  Looking at the failed command I notice that there are no -L
directives.  Wouldn't this have over-ridden my LD_LIBRARY_PATH?  In any case
I have removed that from my shell environment and everything is now building.

Thanks,

Patrick

Patrick Mahan
Lead Technical Kernel Engineer
Adara Networks
Disclaimer: The opinions expressed here are solely the responsibility of the 
author and are not to be
construed as an official opinion of Adara Networks.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Problems building world with 9.0 RC3

2012-01-09 Thread Patrick Mahan
All,

I am having an issue with getting buildworld to work for me.  It is failing
while building zfs -

cc -DADARA_OS  
-I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common
 
-I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/compat/opensolaris/include
 
-I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/compat/opensolaris/lib/libumem
 
-I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../sys/cddl/compat/opensolaris
 
-I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/head
 
-I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libuutil/common
 
-I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libzfs/common
 
-I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libumem/common
 
-I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libnvpair
 
-I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common
 
-I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs
 
-I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys
 
-I/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/common/zfs
 -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-pointer-sign 
-Wno-unknown-pragmas  -o zfs zfs_main.o zfs_iter.o -lbsdxml -lgeom -lm -lnvpair 
-lsbuf -lumem -lutil -luutil -lzfs
/lib/libthr.so.3: undefined reference to `__pselect@FBSDprivate_1.0'
/data/pmahan/devel/pm_ipr9.0/ipr9.0/amd64/obj/data/pmahan/devel/pm_ipr9.0/ipr9.0/src/tmp/usr/lib/libzfs.so:
 undefined reference to `openat@FBSD_1.2'

Now, when I take a look at libpthr.so.3 I for '__pselect' I find -

pmahan@libthr 90  readelf --symbols libthr.so.3 | grep __pselect 
   
   455: c000   120 FUNCGLOBAL DEFAULT   11 
___pselect@@FBSDprivate_1.0
   624: c000   120 FUNCGLOBAL DEFAULT   11 ___pselect

So I see the symbol there but with a double @ not a single.  I don't see any 
errors generated
when libthr.so.3 is being built so I'm a bit of a loss to understand this.  I 
saw in my googling that
the wacky symbol naming was introduced sometime in 8.x, but I I couldn't find 
anything explaining
the symbol generation.

So I am looking for pointers on how to track this one down.  Is this a compiler 
issue?

Thanks,

Patrick___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org