Bug 287300 - lang/ocaml: remove PIE_UNSAFE and fix minor style
Summary: lang/ocaml: remove PIE_UNSAFE and fix minor style
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-06-04 16:23 UTC by Siva Mahadevan
Modified: 2025-08-07 14:17 UTC (History)
2 users (show)

See Also:
freebsd: maintainer-feedback-


Attachments
[PATCH] lang/ocaml: remove PIE_UNSAFE and fix minor style (2.21 KB, patch)
2025-06-04 16:23 UTC, Siva Mahadevan
siva: maintainer-approval? (freebsd)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Siva Mahadevan freebsd_committer freebsd_triage 2025-06-04 16:23:02 UTC
Created attachment 260977 [details]
[PATCH] lang/ocaml: remove PIE_UNSAFE and fix minor style

Patch attached.
Comment 1 Benjamin Jacobs 2025-06-14 13:13:48 UTC
Hello,

Thank you for your interest in lang/ocaml. I need a bit of time to test this patch.
Also, if possible I'd like to find a way to get the ocaml patch in D48228 landing first, as that would remove the binutils dependency on ARM.
Comment 2 Benjamin Jacobs 2025-08-07 14:16:56 UTC
Hi again,

So the PIE_UNSAFE does seem indeed not useful.
The =! construct had been suggested to me before the switch from bsd.ocaml.ml to Mk/Uses, the former was hooked before the Mk/Uses machinery and hence I believe this was a more cautious way (but not relevant anymore, indeed). The good news is that I've finally been able to get access to a powerpc64 system, and I've been able to confirm that everything works fine with clang only.
As mentioned, I had made a patch to fix the aarch64 assembler emitter (D48228) so that it ocaml works with the base clang too. In other words, I don't think it make sense to commit your patch as of now; I'd prefer to have  everyting done (i.e. remove all the arch special-casing) as a single ocaml update.
I'm trying to find some time to prepare an new update to superseed D48228 which would be more limited in scope (as that was the reason given to me to not act on it) to move forward.

Best regards,

Benjamin