devel/coccinelle binaries broken at installation time

[ftigeot]

spatch from devel/coccinelle always returns various errors such as Unknown option -sp_file whereas sp_file is a supported argument

It turns out only the installed binary is broken: building coccinelle with dports and running the spatch program from /usr/obj/dports/devel/coccinelle/work/coccinelle-1.0.0-rc18 works fine.

The difference between the two binaries is stripping: the non-working binary in /usr/local is stripped and the working one is not:

/usr/local/share/coccinelle/spatch: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for DragonFly 3.0.700, stripped

/usr/obj/dports/devel/coccinelle/work/coccinelle-1.0.0-rc18/spatch: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for DragonFly 3.0.700, not stripped

[ftigeot]

Stripping ocaml binaries is potentially dangerous. For example, the document at https://fedoraproject.org/wiki/Packaging:OCaml?rd=Packaging/OCaml says: "There is one exception where a binary should not be stripped. If the package was compiled with ocamlc -custom then the package contains bytecode which strip will remove, thus rendering the binary inoperable"

The devel/coccinelle port uses the -custom flag on my machine.

[jrmarino]

From the description, this sounds like the port is broken at the ports level (before dports). If so, we should be opening a FreeBSD GNATS PR with a suggested fix.

[jrmarino]

Hi, will there be a follow up? Has a PR already been submitted that I can follow (or take responsibility for)?

[ftigeot]

Joris is still investigating the issue and no FreeBSD PR has been opened AFAIK.

[jorisgio]

The issue is that the ports builds either the bytecode object either the native one. But both are installed under the same name (unless both of them are installed). I don't really understand how to configure that. If the bytecode object is build, it should not be stripped because the executable is built with a deprecated ocaml option which does not follow the ELF spec.

The only solution i can suggest w/o digging into the upstream build system and patching it (which i failed at) is to disable strip

[jrmarino]

Now that all the ocaml ports have been updated at the freebsd level, and dports == ports in these cases, please tell me what should be change so that ports does the right thing. Is the port that needs changing lang/ocaml itself?

[jorisgio]

Summary : Ocaml can be built to native ELF binary or to a portable bytecode. The ocamlc compiler builds to bytecode and the ocamlopt compiler builds to native. the issue comes from the uses of the ocaml compiler flags -custom when building to bytecode. This is flag is somehow deprecated because it produce elf files which do not follow the ELF format exactly. Hence, when you try to strip such a file, you actually strip the bytecode from it and it corrupts the binary.

There are a few possible fix here : 1) disable strip (the easy solution) 2) force the port to be built to native code, but i failed to do so because i don't really understand the build system or only strip when built to native. 3) remove the use of -custom but that's probably something for upstream.

[jrmarino]

This should be fixed with the ocaml 4.01.00 import, but I have not confirmed it (nor do I know how to confirm it).

Joris, can you tell me if this is now fixed with the latest ports/packages?

[jorisgio]

Hi, I didn't test all the combinations of build options, but the issue is fixed for the binary pkg, at least.

[jorisgio]

Well, to make it clear, the upstream bug is not fixed if that was your question, stripping the executable stills fails, but since the package is not stripped it works.

[jrmarino]

I wasn't asking about upstream. I am happy that coccinelle and other ocaml ports should work out of the box with how ocaml 4.01.00 is built. I think we can close the issue now. (reopen if you disagree)