Add Socket.so link to perlembed doc

[atoomic]

When using xs_init we need to link the
binary to the .so files in order to be able
to call the boot_* function.

Note: not sure if ExtUtils::Embed can provide
a way to get the path of the .so file

[atoomic]

Pull Request just there for code review

[Leont]

This is almost certainly the wrong change. I would instead suggest is to remove all references to boot_Socket.

Such a thing would only be needed on a perl without dynamic loading, And then all XS extensions that will be used would need to be mentioned and linked in correctly. Effectively long stopped supporting such a scenario.

[atoomic]

@Leont indeed removing the boot_Socket references would solve the compilation issue,
but I think the purpose was to pre-compile one interpreter with one XS module.

I do not think we can compile the providing example without linking it to the .so file.

[Leont]

but I think the purpose was to pre-compile one interpreter with one XS module.

That is not a sensible purpose in 2019. I'm not aware of any platform that runs perl but doesn't have dynamic loading, for that matter (I think the last such platform was DOS). This stuff is dead.

I do not think we can compile the providing example without linking it to the .so file.

Then perhaps we should just delete the entire section.

[atoomic]

Yes you are right the section Using Perl modules, which themselves use C libraries, from your C program still makes sense but the example provided how to be able to compile using Socket is probably useless as you can now load XS without any issues.

I think deleting the section is probably the correct thing to do.

[atoomic]

mm after second reflection not sure we should delete it,
creating a C program which use a Perl module, seems legitimate and in this case we show how to compile a module that also load a C library..

This is uncommon usage, but I can the value of it, for example B::C programs are pretty close to that and linking with the .so file makes sense to me...

[Leont]

creating a C program which use a Perl module, seems legitimate and in this case we show how to compile a module that also load a C library..

We probably need to rewrite this thing from scratch.

[Corion]

When using LLVM to generate a WASM target, it's currently not possible to dynamically link XS code. WebPerl needs this feature to statically link modules like Text::CSV_XS for example.

[tonycoz]

When using LLVM to generate a WASM target, it's currently not possible to dynamically link XS code. WebPerl needs this feature to statically link modules like Text::CSV_XS for example.

Doesn't Webperl do that by adding those modules at perl build time and statically linking everything? It seems irrelevant to this PR.

[xsawyerx]

Looping in @haukex to answer for WebPerl. :)

[tonycoz]

You can dump members of %Config on the sample page to see that WebPerl is built with -Uusedl and many static_exts, including WebPerl Cpanel/JSON/XS

[haukex]

WebPerl builds with d_dlopen='undef', dlsrc='none', and a whole bunch of static_exts. Currently, in the default WebPerl build, the only non-core XS module is Cpanel::JSON::XS. You can see the current hints file here (it uses some env vars from here). The build script unpacks extensions such as Cpanel::JSON::XS into the ext dir in the Perl sources before starting the Perl core build.

So yeah, currently WebPerl requires all XS code to be statically linked into the perl binary. When I first developed WebPerl, support for dynamic loading was experimental in Emscripten and came with serious limitations. Although I could certainly test it again at some point, it would be good to keep support for static linking, if that's what we're talking about :-)

I've skimmed this issue and I have to admit I don't yet understand if this affects the way WebPerl is built :-/

[tonycoz]

From the discussion this doesn't appear to be a reasonable change, I'll close this soonish if no-one objects.