-Wl,--no-as-needed support for Foreign

[avsm]

Some investigation reveals that there is no one combination that works out-of-the-box, since:

• --no-as-needed is required on Ubuntu >=11.10
• --no-as-needed is no longer recognized in MacOS X since >= Lion.

So a configure-time flag is mandatory. I'm wondering if embedding this directive in foreign.cma (via -cclib at configure-time) makes sense? The assumption is that every consumer of foreign.cma will need to force linking, so including the correct compiler option in Ctypes.Foreign makes sense.

I can cook up a patch if you think this sounds right...

(PS: also noticed that twitter/hadoop-lzo#34 has the same bug for their software)

[yallop]

Ah, that's a shame. It'd be nice to have some equivalent of Common Lisp's &allow-other-keys in command-line tools.

Embedding the directive with -cclib makes sense, though. A patch would certainly be welcome.

[yallop]

It turns out that embedding -Wl,--no-as-needed in ctypes.foreign almost works, but we end up with the linker options in the "wrong" order. If you link a.cmxa and b.cmxa (where b depends on a) into an executable

   ocamlopt -o executable a.cmxa b.cmxa

then the flags embedded in b are passed to the linker before the flags embedded in a — something like

  gcc -o executable  ... b.a a.a ... --flags-in-b --flags-in-a ...

In the case of ncurses (for example), this means that -lncurses is passed before -Wl,--no-as-needed, which is no good, since --no-as-needed only applies to libraries that follow.

[avsm]

Is this link order defined in the OCaml manual, or is it simply the result of an unfortunately missing List.rev somewhere in the linker code? Reversing the flags deliberately seems like an odd decision...but changing the behaviour now by default will probably break existing code.

-anil

On 10 Sep 2013, at 13:15, yallop notifications@github.com wrote:

It turns out that embedding -Wl,--no-as-needed in ctypes.foreign almost works, but we end up with the linker options in the "wrong" order. If you link a.cmxa and b.cmxa (where b depends on a) into an executable

ocamlopt -o executable a.cmxa b.cmxa
then the flags embedded in b are passed to the linker before the flags embedded in a — something like

gcc -o executable ... b.a a.a ... --flags-in-b --flags-in-a ...
In the case of ncurses (for example), this means that -lncurses is passed before -Wl,--no-as-needed, which is no good, since --no-as-needed only applies to libraries that follow.

—
Reply to this email directly or view it on GitHub.

[yallop]

I don't see anything explicit in the manual about the order in which things are passed to the platform linker. Still, it's probably essential that both objects and linker options are passed in the reverse order to that specified on the ocamlopt command-line. With ocamlopt dependencies are leaf-last, and with gcc/ld they're leaf first, and order is significant for both objects and various options (-l and -L, for a start).

[avsm]

Ahh yes, I'd missed the inversion of dependency order between the two tools. That makes sense.

[yallop]

Another possibility is to build an executable that can be run during configuration/compilation of a library that uses ctypes to determine the link flags. WxWidgets (for example) comes with such a program:

$ wx-config --libs
-L/usr/local/lib -pthread   -lwx_gtk2u_xrc-2.9 -lwx_gtk2u_html-2.9 -lwx_gtk2u_qa-2.9 -lwx_gtk2u_adv-2.9 -lwx_gtk2u_core-2.9 -lwx_baseu_xml-2.9 -lwx_baseu_net-2.9 -lwx_baseu-2.9 

It's not as neat as embedding the flags in ctypes.foreign, but should be straightforward to get working.