[Buildroot] [PATCH] Fix microperl

[Buildroot] [PATCH] Fix microperl

[Arnout Vandecappelle]

It misses -lm when compiling miniperl

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
This is actually a quite old perl version, and it's not even converted
to GENTARGETS.  Should we deprecate it?

 package/microperl/microperl.mk |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/package/microperl/microperl.mk b/package/microperl/microperl.mk
index b68e825..de5ecd6 100644
--- a/package/microperl/microperl.mk
+++ b/package/microperl/microperl.mk
@@ -32,7 +32,7 @@ $(MICROPERL_DIR)/.source: $(DL_DIR)/$(MICROPERL_SOURCE)
 
 $(MICROPERL_DIR)/.host_configured: $(MICROPERL_DIR)/.source
 	# we need to build a perl for the host just for Errno.pm
-	(cd $(MICROPERL_DIR); ./Configure -Dcc="$(HOSTCC)" -de  )
+	(cd $(MICROPERL_DIR); ./Configure -Dcc="$(HOSTCC)" -de -A libs='-lm' )
 	touch $@
 
 
-- 
tg: (dca6e03..) t/fix-microperl (depends on: master)

[Buildroot] [PATCH] Fix microperl

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> writes:

 Arnout> It misses -lm when compiling miniperl
 Arnout> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

Committed, thanks.

 Arnout> ---
 Arnout> This is actually a quite old perl version, and it's not even converted
 Arnout> to GENTARGETS.  Should we deprecate it?

Well, I think getting rid of it would be a pity, but I don't personally
use perl so if nobody else is using it? Gustavoz?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] Fix microperl

[Joshua Jackson]

It gets auto-built with the selection of the autoconf / automake
packages... I'm not sure if it is 100% required, but I do know that if
you are building a system that you plan to use to compile other
software, some flavor of perl is often needed by the config scripts.

I bumped into this issue when attempting to create a system image with
all of the necessary development tools for me to compile software for
the embedded system I am working on... I know it can simply be
cross-compiled, but being able to create a virtual appliance or chroot
tree for people to build software for the target system in is handy.

Josh

On Tue, Mar 6, 2012 at 4:21 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Arnout" == Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> writes:
>
> ?Arnout> It misses -lm when compiling miniperl
> ?Arnout> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>
> Committed, thanks.
>
> ?Arnout> ---
> ?Arnout> This is actually a quite old perl version, and it's not even converted
> ?Arnout> to GENTARGETS. ?Should we deprecate it?
>
> Well, I think getting rid of it would be a pity, but I don't personally
> use perl so if nobody else is using it? Gustavoz?
>
> --
> Bye, Peter Korsgaard
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [PATCH] Fix microperl

[Thomas Petazzoni]

Hello,

Le Tue, 06 Mar 2012 22:21:32 +0100,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

> Well, I think getting rid of it would be a pity, but I don't
> personally use perl so if nobody else is using it? Gustavoz?

Gustavo has a patch that does the conversion to GENTARGETS, he even
posted it on the list at:

From: Gustavo Zacarias <gustavo@zacarias.com.ar>
To: buildroot at busybox.net
Subject: [Buildroot] [PATCHv3] [RFC] microperl: bump to version 5.12.3 and convert to gentargets
Date: Tue, 17 May 2011 15:22:39 -0300

There was only one remaining issue: on a Ubuntu 64 bits host, the build
was failing. But I think it also fails in the current state, so the
patch that converts to GENTARGETS could be merged, and the building
problem on Ubuntu 64 bits solved later.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] Fix microperl

[Gustavo Zacarias]

On 2012-03-07 05:06, Thomas Petazzoni wrote:

> Hello,
>
> Le Tue, 06 Mar 2012 22:21:32 +0100,
> Peter Korsgaard <jacmet@uclibc.org> a ?crit :
>
>> Well, I think getting rid of it would be a pity, but I don't
>> personally use perl so if nobody else is using it? Gustavoz?
>
> Gustavo has a patch that does the conversion to GENTARGETS, he even
> posted it on the list at:
>
> From: Gustavo Zacarias <gustavo@zacarias.com.ar>
> To: buildroot at busybox.net
> Subject: [Buildroot] [PATCHv3] [RFC] microperl: bump to version
> 5.12.3 and convert to gentargets
> Date: Tue, 17 May 2011 15:22:39 -0300
>
> There was only one remaining issue: on a Ubuntu 64 bits host, the 
> build
> was failing. But I think it also fails in the current state, so the
> patch that converts to GENTARGETS could be merged, and the building
> problem on Ubuntu 64 bits solved later.
>
> Best regards,
>
> Thomas

It has a limitation on modules at the moment, they must be of the pm 
(interpreted) type rather than the more complex xs ones (C usually).
That's because full perl is required for xs which in turn requires a 
full-blown configuration.
For the most part it checks for libc functions and presence of other 
libs, and platform details (sizeof... and so on).
At the moment this would be "important" (not for me though) to get 
target autoconf/automake going since there are new required modules 
which are XS when the auto* packages were versioned bumped.
The proper solution would probably be define the lowest denominator for 
libc, say uclibc-0.9.31, generate a cache on a qemu/working target and 
get that back into the package.
For the platform details it would be the same work.
This is more or less the way OE and OpenWRT do it.
And then there's module hell if we plan on Kconfig-ing those in an easy 
way for users :)
But i would split that into a proper perl package maybe, or with a 
config kludge.
Regards.

[Buildroot] [PATCH] Fix microperl

[Thomas Petazzoni]

Le Wed, 07 Mar 2012 12:29:21 -0300,
Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :

> It has a limitation on modules at the moment, they must be of the pm 
> (interpreted) type rather than the more complex xs ones (C usually).
> That's because full perl is required for xs which in turn requires a 
> full-blown configuration.

Ok.

> For the most part it checks for libc functions and presence of other 
> libs, and platform details (sizeof... and so on).
> At the moment this would be "important" (not for me though) to get 
> target autoconf/automake going since there are new required modules 
> which are XS when the auto* packages were versioned bumped.

Could you expand on this, because I'm not sure I got what you said.

> The proper solution would probably be define the lowest denominator
> for libc, say uclibc-0.9.31, generate a cache on a qemu/working
> target and get that back into the package.

A bit like what we do for ./configure scripts already, at the end of
package/Makefile.in, correct?

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] Fix microperl

[Gustavo Zacarias]

On 2012-03-07 12:50, Thomas Petazzoni wrote:

>> For the most part it checks for libc functions and presence of other
>> libs, and platform details (sizeof... and so on).
>> At the moment this would be "important" (not for me though) to get
>> target autoconf/automake going since there are new required modules
>> which are XS when the auto* packages were versioned bumped.
>
> Could you expand on this, because I'm not sure I got what you said.

It's like configure scripts do, except that perl has it's own build 
system.

>> The proper solution would probably be define the lowest denominator
>> for libc, say uclibc-0.9.31, generate a cache on a qemu/working
>> target and get that back into the package.
>
> A bit like what we do for ./configure scripts already, at the end of
> package/Makefile.in, correct?

Something similar but quite perl-specific for the reason stated above.
Once the perl Configure script runs it generates a config.sh file that 
contains all the needed definitions.
What microperl does is define a subset uconfig.sh file with the basics 
only which doesn't allow for XS modules to be built, basically a 
barebones interpreter.
The native way for perl to be built as a fully-fledged perl (sic) is to 
run the tests on the target host via ssh/telnet or some other method and 
fetch back the results to generate config.sh
The details of the target are basically stored in Config.pm and it's 
includes, that's the trick i use to build modules in 
MICROPERL_BUILD_EXTENSIONS by using host-perl overriding it's config 
with PERL5LIB.
Regards.