dtrace discuss - Jun 2008 - Xorg dtrace probes failing to build on FreeBSD

Any idea why this is failing?   (I''m confused as to why it''s
complaining
about /usr/lib/dtrace/psinfo.d, which isn''t part of Xorg at all.  The
Xorg Xserver.d file can be seen at at:
http://cgit.freedesktop.org/xorg/xserver/tree/dix/Xserver.d )

These probes have built fine on Solaris for a couple of years, but are
disabled in the MacOS X builds of Xorg since MacOS doesn''t do dtrace
-G,
and no one has been found who has both a desire to fix MacOS X dtrace
builds & access to a Leopard box.   (Apple''s Xorg guys have a long
list
of higher priority issues to fix in their build.)

	-Alan Coopersmith-           alan.coopersmith at sun.com
	 Sun Microsystems, Inc. - X Window System Engineering

-------- Original Message --------
Subject: xorg build problems: dtrace script
Date: Wed, 18 Jun 2008 15:43:03 -0400
From: Chuck Robey <chuckr at telenix.org>
To: xorg at lists.freedesktop.org

I''ve never seen this type of thing before.  Is it a precompiler of some
sort?
It''s getting an error, looks like it''s tripping over a common
FreeBSD type, a
uid_t.  I know how I''d handle this with a C file, I''d find out
where it was
defined, see if it was already included but had define masking problems, or if
it just plain wasn''t included before, and then add an include for it,
but I
don''t know what the heck this thing is ... code is /usr/lib?? 
that''s wacky ...

Anyhow, here''s the last part of the error listing (from xserver,dix). 
If you
don''t recognize the error, but know something about the .d files, you
could tell
me, then I could pester the FreeBSD folks about it:

ranlib .libs/libdix.a
creating libdix.la
(cd .libs && rm -f libdix.la && ln -s ../libdix.la libdix.la)
/usr/sbin/dtrace -G -C -o dtrace-dix.o -s ../dix/Xserver.d .libs/*.o
dtrace: failed to compile script ../dix/Xserver.d:
"/usr/lib/dtrace/psinfo.d",
line 37: syntax error near "uid_t"
*** Error code 1

Stop in /home/chuckr/xorgsrc/xserver/dix.
*** Error code 1

Stop in /home/chuckr/xorgsrc/xserver/dix.
*** Error code 1

Stop in /home/chuckr/xorgsrc/xserver.
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

The reason why it is failing is because the CTF data generation for the kernel
is currently opt-in rather than enabled by default. This was done to allow the
early adopters a chance to try it before defaulting it to on (as it will be
eventually).

The only way that libdtrace can determine the type of uid_t on FreeBSD is to get
the info from CTF in the kernel. Without that CTF, the library D script parse
fails.

Userland tracing isn''t supported yet in FreeBSD, so the Xorg build is
being a bit adventurous trying to use ''dtrace'' in
it''s build simply because it is installed.

The FreeBSD port should have had the dtrace build option turned off by now.
I''m not sure why it hasn''t. :-)


--
This message posted from opensolaris.org

John Birrell wrote:
> The reason why it is failing is because the CTF data generation for the
kernel is currently opt-in rather than enabled by default. This was done to
allow the early adopters a chance to try it before defaulting it to on (as it
will be eventually).
> 
> The only way that libdtrace can determine the type of uid_t on FreeBSD is
to get the info from CTF in the kernel. Without that CTF, the library D script
parse fails.
> 
> Userland tracing isn''t supported yet in FreeBSD, so the Xorg build
is being a bit adventurous trying to use ''dtrace'' in
it''s build simply because it is installed.
Well, that''s the GNU autoconf way - if you find a feature, you
use it.   Is there a better test we should put in there to determine
if it''s safe to use on FreeBSD or should we just add freebsd* to
darwin* in the OS matching patterns in the blacklist for now?

-- 
	-Alan Coopersmith-           alan.coopersmith at sun.com
	 Sun Microsystems, Inc. - X Window System Engineering

On Thu, Jun 19, 2008 at 07:50:06AM -0700, Alan Coopersmith
wrote:
> John Birrell wrote:
> > The reason why it is failing is because the CTF data generation for
the kernel is currently opt-in rather than enabled by default. This was done to
allow the early adopters a chance to try it before defaulting it to on (as it
will be eventually).
> > 
> > The only way that libdtrace can determine the type of uid_t on FreeBSD
is to get the info from CTF in the kernel. Without that CTF, the library D
script parse fails.
> > 
> > Userland tracing isn''t supported yet in FreeBSD, so the Xorg
build is being a bit adventurous trying to use ''dtrace'' in
it''s build simply because it is installed.
> 
> Well, that''s the GNU autoconf way - if you find a feature, you
> use it.   Is there a better test we should put in there to determine
> if it''s safe to use on FreeBSD or should we just add freebsd* to
> darwin* in the OS matching patterns in the blacklist for now?
I suggest that Xorg does nothing. The FreeBSD port needs to have the without
dtrace config otion set in the configure definition. This is easy to do.
I''m not a ports committer, so I can''t do it myself. I assumed
that because
this was mentioned in a topic on ports@ that it would be done.

--
John Birrell