tech-pkg archive

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

Re: lang/ruby200-base fails to build on NetBSD with DTrace

Leonardo Taccari <> writes:

> Hello Greg,
> Greg Troxel writes:
>> Is enough of dtrace always built with NetBSD for using dtrace to make
>> sense (vs being an option)?  Generally, pkgsrc tries to avoid
>> compile-time detection in favor of requiring features or hiding them
>> (via bl3).
> You're right, I think that a dtrace option (like lang/perl5) is better,
> depending on ${OPSYS}.

I built ruby200-base on netbsd-7 amd64 (with no MK options), and it
built fine.

So my impression is that during the freeze, no changes are needed.

>> But, we don't really have a good way to deal with things that are
>> optional in the base system.  It seems with dtrace there are some MK
>> variables to set in the build, rather than it being standard.

Historically, headers were always installed for optional kernel
features, so that code would compile and then work or not at runtime.
But DTRace seems big enough that we aren't always building the userland

>> So I wonder if you are building on a stock netbsd-7 machine, or if
>> you've enabled dtrace specifically.
> Yes, I'm running NetBSD-current built with MKDTRACE=yes and MKCTF=yes in
> order to fully enable DTrace.

So there are two things to fix:

  figure out and fix DTrace support in your environment

  decide how to deal with optional DTrace support in packages.
  Probably adding it to PKG_SUPPORTED_OPTIONS on systems where it might
  work is in order.   Alternatively there should probably  be a
  mk/ that somehow deals with this, turning it into a
  pseudo-package, so that each program doesn't have repeated logic.

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index