Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-Dextras not being handled #80

Open
th0ma7 opened this issue Aug 27, 2019 · 8 comments
Open

-Dextras not being handled #80

th0ma7 opened this issue Aug 27, 2019 · 8 comments

Comments

@th0ma7
Copy link

th0ma7 commented Aug 27, 2019

I've been trying to get perl to compile against spksrc for synology NAS. Gladly I've found your project and pretty much everything started working (just wow!).

I have one issue pending related to compiling extras modules. It seems I just can't get the -Dextras="ABC::DEF" to be handled in order to get all necessary modules to be built.

Any hints you might have to help help? Thnx in advance!

@arsv
Copy link
Owner

arsv commented Aug 27, 2019

Download the modules you need, and unpack them into cpan/ before running configure.
Check existing modules there to see how directory structure should look like. For compiled (XS) modules, you want cpan/Foo-Bar/Makefile.PL for a module called foo-bar-X.Y.

Upon invocation, configure will pick all modules present in cpan/, whether or not they are listed in MANIFEST. No extra arguments are needed to trigger that. Just to be sure, check extensions= line in config.sh after running configure.

perl-cross itself will not download anything from CPAN, it has to be done externally.

@th0ma7
Copy link
Author

th0ma7 commented Aug 27, 2019

That explains, thnx a lot! Will give it a try.
Does it handle dependencies? meaning if I've downloaded all dependencies will it process them in the right order automagically?

@arsv
Copy link
Owner

arsv commented Aug 27, 2019

No, configure doesn't really handle dependencies even for the core modules.
Modules from cpan/ will be built in alphabetical order their directories.

It's up to you to download all soft (run-time) dependencies for you modules. The order in which soft dependencies are built is not important anyway, as long as all of them end up in the target installation.

Hard (build-time) dependencies, when module A cannot be built before module B, are generally incompatible with cross-compiling and require fixing the modules somehow. This is because module B will be built for the target while whatever code in A needs it would have to run on the build host with miniperl instead of full perl. Check miniperl_top and cnf/stubs/ to see how hard dependencies on core modules are handled currently.

@th0ma7
Copy link
Author

th0ma7 commented Aug 29, 2019

I eneded-up creating a script that uses cpanm to get the info and all dependencies, download them all and untar them into the perl-0.30.0/cpan directory directly.

Sadly that didn't worked out. The extras variable in config.sh stays empty. I've also tried generating a extras.lst file but it did not process it. Only thing I notice for now is that the new directories under cpan also contains -version at the end which might explain why it isn't picking them up...

@arsv
Copy link
Owner

arsv commented Aug 29, 2019

The modules should be in extensions just like the those shipped within the perl source. Not in extras, that variable is not used by perl-cross.

Version suffix should not prevent it from picking the modules up, but I just checked and it looks like versioned modules end up disabled. Must be a bug somewhere. Version suffixes would mess up values in config.sh anyway, so maybe try renaming the directories to match mainline perl naming scheme there.

@th0ma7
Copy link
Author

th0ma7 commented Aug 30, 2019

Removing the trailing version number solved it. And indeed it is the extensions variable in config.sh that gets populated accordingly. Thnx for the tip.

Dependency issues gets hit real hard real fast such as:
Can't locate Alien/Build/MM.pm in @INC (you may need to install the Alien::Build::MM module)
I'm cross-building from x86_64 to x86_64 so I guess I could create cnf/stubs/ files but wow, it looks like a heck of another ride to get into (perhaps another time).

Initial solution was to build modules directly on the end-state platform using my crossed-built version (e.g. creating a synology package from a VM) but I hit the following on some essential modules I need:

In file included from ReadKey.xs:5:0:
/var/packages/perl/target/lib/perl5/5.30.0/x86_64-linux/CORE/perl.h:736:24: fatal error: xlocale.h: No such file or directory
 #   include <xlocale.h>

So I end-up being stuck both-ways (unable to cross-build modules & unable to locally build modules)... Perhaps there is an easy fix you found previous that could help out for the xlocale.h ?

@arsv
Copy link
Owner

arsv commented Aug 30, 2019

Quick look at Alien::Build makes me think it may be worse than just dependencies. Alien builds external code, but I don't see any mention of cross-compiling there. Chances are it's about adding support for cross-compiling environments to Alien. Or fixing dependent modules to not use Alien, and rely instead on prebuilt libraries.

The best I can tell, xlocale.h is not a perl header. It was probably present on the build system but missing on the target system. There's no real support for target builds in perl-cross (it doesn't run configure on the target system) so the only way it would work is if the target has the same exact headers and libraries as the build system.

@th0ma7
Copy link
Author

th0ma7 commented Aug 30, 2019

Again thnx for the quick reply.
Target system has the libraries but is missing the header in question (and perhaps a few others). I might give it a shot a pre-packaging only "trivial" cpan modules I need, include as well a few headers I find missing on my system from the cross-build environment and see where this gets me.
Thnx!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants