2 cpu's on gkrellm?

Hi,

I've just started running dual cpu's with the multiprocessor kernel.
Both CPU's are running no problem.

However gkrellm, doesn't show 2 cpu's though?
(it does on a dual cpu box at work running linux)

Is gkrellm supposed to show 2 cpu's with netbsd?
any ideas or help appreciated,

thanks,
Paul.

--
____________________________________________
Paul           (pts <at> bom.gov.au)
Australian Bureau Of Meteorology
____________________________________________

New compiler selection framework committed

I've committed a new compiler selection framework that replaces the
functionality of the old compiler.mk.  If you have any of the following
variables in /etc/mk.conf, then be aware that they're deprecated and
will likely be removed altogether after the next pkgsrc branch date:

	USE_GCC2
	USE_GCC3
	USE_SUNPRO
	USE_MIPSPRO

The way to select the compiler using the new framework is to set
PKGSRC_COMPILER in /etc/mk.conf.  The following is excerpted from
Packages.txt:

---
By default, pkgsrc will use GCC to build packages.  This may be
overridden by setting the following variables in /etc/mk.conf:

 * PKGSRC_COMPILER:
   This is a list of values specifying the chain of compilers to invoke
   when building packages.  Valid values are:

        distcc          distributed C/C++ (chainable)
        ccache          compiler cache (chainable)
        gcc             GNU
        mipspro         Silicon Graphics, Inc. MIPSpro
        sunpro          Sun Microsystems, Inc. WorkShip/Forte/Sun
                        ONE Studio

   The default is "gcc".  You can use ccache and/or distcc with an

Re: ORBit didn't buildlink any include or libraries

On Sat, 31 Jan 2004, Min Sik Kim wrote:

> Did you try 'find work.puget/.x11-buildlink/'?

I guess you mean .buildlink-x11. Normally it is the same directory (a
symlink to .buildlink).

>  I found the following
> lines in mk/buildlink3/bsd.buildlink3.mk (lines 497-500).
>
> 	case ${BUILDLINK_PREFIX.${_pkg_}} in				\
> 	${X11BASE})     buildlink_dir="${BUILDLINK_X11_DIR}" ;;		\
> 	*)              buildlink_dir="${BUILDLINK_DIR}" ;;		\
> 	esac;								\
>
> So, if X11BASE = BUILDLINK_PREFIX.glib as in your case, buildlink is
> done in BUILDLINK_X11_DIR, instead of BUILDLINK_DIR.
>
> It doesn't matter if USE_X11 is set, because then BUILDLINK_X11_DIR is
> just a symlink to BUILDLINK_DIR.

Yes. I was thinking it was always a symlink.

Another part of my problem as seen with qt3-libs is that
${BUILDLINK_PREFIX.${.TARGET:S/-buildlink//}} is always blank for all of
the xlibs but fine with other included buildlinks. So then the PREFIX is
chopped off and it doesn't find a file, like starting with
/include/whatever.h on system.

   Jeremy C. Reed

Re: ORBit didn't buildlink any include or libraries

* Jeremy C. Reed:
> On Sat, 31 Jan 2004, Min Sik Kim wrote:
> 
> > Did you try 'find work.puget/.x11-buildlink/'?
> 
> I guess you mean .buildlink-x11. Normally it is the same directory (a
> symlink to .buildlink).

No, I meant .x11-buildlink.  See Line 50 in bsd.buildlink3.mk (r1.65).
Moreover, it is different from .buildlink unless USE_X11 is defined.
That's why you cannot find any header or library link in .buildlink.
They are created in .x11-buildlink in your case because X11_BASE =
BUILDLINK_PREFIX.* (Line 497).

--

-- 
Min Sik Kim

Re: ORBit didn't buildlink any include or libraries

On Sat, 31 Jan 2004, Jeremy C. Reed wrote:

> On Sat, 31 Jan 2004, Min Sik Kim wrote:
>
> > Did you try 'find work.puget/.x11-buildlink/'?
>
> I guess you mean .buildlink-x11. Normally it is the same directory (a
> symlink to .buildlink).

Okay I looked at this again. I see it is work/.x11-buildlink and it is not
a symlink. (That must be for buildlink3.)

> > lines in mk/buildlink3/bsd.buildlink3.mk (lines 497-500).
> >
> > 	case ${BUILDLINK_PREFIX.${_pkg_}} in				\
> > 	${X11BASE})     buildlink_dir="${BUILDLINK_X11_DIR}" ;;		\
> > 	*)              buildlink_dir="${BUILDLINK_DIR}" ;;		\
> > 	esac;								\
> >
> > So, if X11BASE = BUILDLINK_PREFIX.glib as in your case, buildlink is
> > done in BUILDLINK_X11_DIR, instead of BUILDLINK_DIR.

I had modified that in my bsd.buildlink2.mk by checking if X11BASE was
LOCALBASE, but not in my bsd.buildlink3.mk yet.

> > It doesn't matter if USE_X11 is set, because then BUILDLINK_X11_DIR is
> > just a symlink to BUILDLINK_DIR.

Is there ever a time when it should not be a symlink?

Re: fixing buildlink to not use lib*.la if not available

On Sat, 31 Jan 2004, Jeremy C. Reed wrote:

> My work directory  has
> /scratch/pkgsrc/x11/qt3-libs/work.puget/.buildlink/.libX11_buildlink_done
> which contains:
>
> /include/X11/ImUtil.h: not found
> /include/X11/XKBlib.h: not found
> /include/X11/Xcms.h: not found
> /include/X11/Xlib.h: not found
> /include/X11/Xlibint.h: not found
> /include/X11/Xlocale.h: not found
> /include/X11/Xresource.h: not found
> /include/X11/Xutil.h: not found
> /include/X11/cursorfont.h: not found
> /include/X11/region.h: not found
> /lib/libX11.*: not found
>
> Hmmm... somewhere my /usr (LOCALBASE) is being chopped off.

I had tried to put the
.include "../../new/xlibs/buildlink2.mk" file directly in my
bsd.buildlink2.mk (and forced to not use x11-links).

But when I got rid of that and manually added
.include "../../new/xlibs/buildlink2.mk" to my qt3-libs/Makefile, they
were linked correctly. Now to let it build longer ...

Later, I will just put that .include directly in my bsd.pkg.mk so it will
work for all pkgsrc using USE_X11. (I had suggested USE_PKGSRC_X=xlibs as

Re: 2 cpu's on gkrellm?

On Sun, 1 Feb 2004, Paul (NCC/CS) wrote:

> I've just started running dual cpu's with the multiprocessor kernel.
> Both CPU's are running no problem.
>
> However gkrellm, doesn't show 2 cpu's though?
> (it does on a dual cpu box at work running linux)
>
> Is gkrellm supposed to show 2 cpu's with netbsd?
> any ideas or help appreciated,

Not gkrellm-1.2.13 -- that's hopeless -- but here's a patch for
gkrellm-2.1.24. (Latest is actually 2.1.25; the patch should apply
cleanly to that, too.) gkrellm-2 builds mostly out-of-the-box.
To build against gtk2 from pkgsrc, I had to move
"/usr/X11R6/lib/libfontconfig.so.1" out of the way, then "gmake
netbsd2 && gmake install_netbsd", then move "libfontconfig.so.1"
back... else you won't even be able to launch an xterm!

gkrellm-2 is client/server, which is really cool if you have a
bunch of hosts but only one Xserver. Works with IPv6, too.

Frederick

diff -ur gkrellm-2.1.24.bak/src/sysdeps/netbsd.c gkrellm-2.1.24/src/sysdeps/netbsd.c
--- gkrellm-2.1.24.bak/src/sysdeps/netbsd.c	2003-10-08 10:51:51.000000000 -0500
+++ gkrellm-2.1.24/src/sysdeps/netbsd.c	2004-01-31 21:37:47.000000000 -0600
 <at>  <at>  -54,27 +54,48  <at>  <at> 
 #include <sys/sysctl.h>
 #include <sys/sched.h>

"Missing symbols" when compiling agains gtk2+...

Pkgsrc vs. X libfontconfig breaks gtk2+ on NetBSD. When you try to
use "pkg-config --libs gtk+-2.0" to get the linker flags, as gkrellm
does, for example, you get lots of missing symbols. This means that
the pkgsrc gtk2+ is essentially broken for daily use; the problem
leaks through sometimes to packages as well.

The deal is, gtk2+ links against pkg libfontconfig.so.1, and many
other libraries as well. What happens is that, when the recursive
search starts with a library in "/usr/X11R6/lib" that needs
libfontconfig.so.1, it uses the DT_RPATH embedded in *that* library
to find the libfontconfig.so.1 in "/usr/X11R6/lib". Even if it pulls
in the libfontconfig.so.1 in "/usr/pkg/lib" later, the symbols in
the "/usr/X11R6/lib" one are first in the search path.

What works, is to add "-Wl,-rpath-link,/usr/pkg/lib:/usr/X11R6/lib"
to "/usr/pkg/lib/pkgconfig/pangoxft.pc". This would, however, surely
break gtk2+ on platforms which don't use gcc to compile. So, can
anyone tell me if there is a way to insert this conditionally, for
some appropriate condition?

Frederick

Re: "Missing symbols" when compiling agains gtk2+...

[...]
> The deal is, gtk2+ links against pkg libfontconfig.so.1, and many
> other libraries as well. What happens is that, when the recursive
> search starts with a library in "/usr/X11R6/lib" that needs
> libfontconfig.so.1, it uses the DT_RPATH embedded in *that* library
> to find the libfontconfig.so.1 in "/usr/X11R6/lib". Even if it pulls
> in the libfontconfig.so.1 in "/usr/pkg/lib" later, the symbols in
> the "/usr/X11R6/lib" one are first in the search path.
[...]

Maybe slightly off-topic, but I guess that's one of the issues fixed with 
the patches [1] I propsed a few days ago. gkrellm2 builds and works just 
fine here.

[1] http://mail-index.netbsd.org/tech-pkg/2004/01/27/0004.html

--

-- 
Marc Recht

Re: "Missing symbols" when compiling agains gtk2+...

On Sun, 1 Feb 2004, Marc Recht wrote:

> > The deal is, gtk2+ links against pkg libfontconfig.so.1, and many
> > other libraries as well. What happens is that, when the recursive
> > search starts with a library in "/usr/X11R6/lib" that needs
> > libfontconfig.so.1, it uses the DT_RPATH embedded in *that* library
> > to find the libfontconfig.so.1 in "/usr/X11R6/lib". Even if it pulls
> > in the libfontconfig.so.1 in "/usr/pkg/lib" later, the symbols in
> > the "/usr/X11R6/lib" one are first in the search path.
>
> Maybe slightly off-topic, but I guess that's one of the issues fixed with
> the patches [1] I propsed a few days ago. gkrellm2 builds and works just
> fine here.
>
> [1] http://mail-index.netbsd.org/tech-pkg/2004/01/27/0004.html

That's a lot of patches, and none of them seem to touch the pkgconfig
files. Are you certain fixing gkrellm isn't just dumb luck? (Maybe we
need those anyway for buildlink; I don't know.)

When you replace a shared library of the stock system, I think it's
never going to work correctly all of the time, unless you can ensure
that "-Wl,-rath-link,${LOCALBASE}/lib..." will be added to the link
command line. I'd like to correct my earlier statement: it's not
actually "pangoxft.pc" that needs the rpath-link, but "fontconfig.pc",
"xft.pc", and "xrender.pc"; "pangoxft" only needs "xft" to be added to
its "Requires" line.

The "Requires" lines are all a mess, by the way. Many of them have
multiple space separated dependencies, while they're supposed to be