Page MenuHomeFreeBSD

lang/python310: Introduce DTRACE option
Needs RevisionPublic

Authored by 0mp on Aug 10 2021, 9:33 AM.


Group Reviewers
lang/python310: Introduce DTRACE option

- Let users compile Python with DTrace support. The option is off by
  default for now.

- Set USES=gmake. It turns out that the Python makefiles contain syntax
  specific to GNU make, which is interpreted by bmake in an unexptected way (in
  particular, $< is not expanded as desired). In order to fix that, let's just
  use GNU make for now.

- Patch the configure script in order to force building of the object files
  required for DTrace support. Here's the problem with the detection mechanism:

  $ dtrace -G -s ./conftest.d -xnolibs -o /tmp/conftest.o
  ld: error: /usr/lib/dtrace/drti.o is incompatible with /tmp/conftest.o.0DHcqI
  dtrace: failed to link script ./conftest.d: failed to link /tmp/conftest.o: ld exited with status 1

Related Issues


Approved by:
Differential_Revision: D31489
Test Plan
  • The port builds fine in poudriere.
  • dtrace -ln 'python*:::' shows some available probes when python3.10 is executing.

Diff Detail

rP FreeBSD ports repository
No Linters Available
No Unit Test Coverage
Build Status
Buildable 40960
Build 37849: arc lint + arc unit

Event Timeline

0mp requested review of this revision.Aug 10 2021, 9:33 AM

Mmm, surprised by this. CPython I don't believe has ever required or had GNU make specific features. Can you identify the introduction of this? Can we fix this with a patch for portability, such that we can submit it upstream? Not upstreamed local changes has been a source of many issues for us in the distant past that we have only recently come out of


Empty line before this. Was DTRACE_WITH=dtrace tested? Did it work, not work? WITH|ENABLE are preferred over ON (particularly without an OFF), as it can cause issues with systems detecting features and building with them, even when the OPTION has been disabled


Is removing the test the correct/complete resolution for upstream, or does this need a freebsd specific call, or a !freebsd specific condition?

0mp edited the summary of this revision. (Show Details)
0mp added inline comments.

It's a tricky one. bmake seems to misunderstand the desired meaning of $< in the Python makefiles. GNU make does the right thing. In a way, we could fix it but the problem is that you'll never be sure if you actually fixed all the issues.

I can prepare a patch that could be submitted upstream, but from my limited perspective it seems to be an unnecessary uphill battle. But then, I'm not a Python maintainer and you surely understand the dynamics better.


I didn't add a newline here, because DEBUG was already in one block with IPV6. I'll add a newline. Should I add one after as well?

Also, WITH should work. I'll give it a try.


The removal works for FreeBSD. If we want to upstream the patch, we must fix the test instead.

From what I understand, the whole point of this test is to check if the dtrace binary supports -G. I'm not sure why the current test is failing to do the right thing on FreeBSD. I'm also not sure what an elegant fix would be.

Forgot one other thing in previous review. dtrace has been an option in Python for a (long) while, and we would want to add this option across all relevent Python ports


Not to say this isn't a gmake'ism, or not an issue, but we would expect other failures of this kind across the board and in the past due to this issue, and I can't recall any of the same kind (I may be wrong, or forgetting).

Could of additional things for this issue:

  • If gmake is (currently) needed, we should do it across the board for all ports, unless this is a (recent) version+ specific issue (need confirmation).
  • Was there an actual failure/impact due to the mentioned syntax when not using gmake? Is it scoped to a/the dtrace option?
  • What might a patch to this look like, to obviate the need to switch to gmake completely, that we may be able to send up stream. Upstream is very approachable and we have a good relationship

Unless you'd like to isolate that (non functional, logically different) changeset into a separate one, which would be preferable, particularly if it affects all/other python port versions. If so, feel free to not worry about it here.


I see an identical error in pkg-fallout (13arm64)

What was the version/arch you saw this linker error on?

Can you see if/where else this fails in the same way for {11,12,13,i386,amd64} at least

koobs requested changes to this revision.Oct 8 2021, 7:43 AM
koobs edited the summary of this revision. (Show Details)
This revision now requires changes to proceed.Oct 8 2021, 7:44 AM