Discussion:
[perl #52956] [BUG] --parrot_is_shared=0 IS shared?
(too old to reply)
Will Coleda
2008-04-16 15:03:27 UTC
Permalink
# New Ticket Created by Will Coleda
# Please include the string: [perl #52956]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52956 >


While trying to put the macport for 0.6.1 together, I noticed that the
install failed.

Tracked it down to the fact that --parrot_is_shared=0 seems to be
generating a parrot that relies on a shared lib.

This is happening for me on osx/86 (but the build works because it's
finding the blib/lib version: once you install it, this fails because
then it can't find the lib.), and on linux/x86 on feather (the build
fails because miniparrot requires the shared library and can't find
it, stopping the build immediately).

This worked as recently as 0.5.2 (the last macport)
--
Will "Coke" Coleda
Will Coleda
2008-04-29 06:52:22 UTC
Permalink
# New Ticket Created by Will Coleda
# Please include the string: [perl #53494]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53494 >


While trying to put the macport for 0.6.1 together, I noticed that the
install failed.

Tracked it down to the fact that --parrot_is_shared=0 seems to be
generating a parrot that relies on a shared lib.

This is happening for me on osx/86 (but the build works because it's
finding the blib/lib version: once you install it, this fails because
then it can't find the lib.), and on linux/x86 on feather (the build
fails because miniparrot requires the shared library and can't find
it, stopping the build immediately).

This worked as recently as 0.5.2 (the last macport)
--
Will "Coke" Coleda
Will Coleda
2009-02-01 18:41:20 UTC
Permalink
I haven't touched this since it was initially reported.

On Sat, Jan 31, 2009 at 10:45 PM, James Keenan via RT
Post by Will Coleda
While trying to put the macport for 0.6.1 together, I noticed that the
install failed.
Tracked it down to the fact that --parrot_is_shared=0 seems to be
generating a parrot that relies on a shared lib.
Coke: Is this still problematic?
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
--
Will "Coke" Coleda
Andrew Dougherty
2009-02-17 15:04:16 UTC
Permalink
Post by Will Coleda
While trying to put the macport for 0.6.1 together, I noticed that the
install failed.
Tracked it down to the fact that --parrot_is_shared=0 seems to be
generating a parrot that relies on a shared lib.
Verified, this still fails[1] as of r36803. This, combined with TT #344,
blocks creation of a functioning macport.
[1] Generates a parrot that depends on libparrot.dylib
That's because Configure.pl doesn't allow you any way to override the
hints file. What I had in mind was a more primitive, ruthless editing of
the darwin hints file, something like this (totally untested)

--- parrot-current/config/init/hints/darwin.pm 2009-02-01 20:44:27.000000000 -0500
+++ parrot-andy/config/init/hints/darwin.pm 2009-02-17 09:55:39.000000000 -0500
@@ -55,20 +55,6 @@
ld_load_flags => '-undefined dynamic_lookup -bundle',
memalign => 'some_memalign',
has_dynamic_linking => 1,
-
- # RT 43147: When built against a dynamic libparrot,
- # installable_parrot records the path to the blib version
- # of the library.
-
- parrot_is_shared => 1,
- libparrot_shared => 'libparrot.$(SOVERSION)$(SHARE_EXT)',
- libparrot_shared_alias => 'libparrot$(SHARE_EXT)',
- rpath => "-L",
- libparrot_soname => "-install_name "
- . $lib_dir
- . $conf->data->get('slash')
- . "libparrot"
- . $conf->data->get('share_ext')
);
}
--
Andy Dougherty ***@lafayette.edu
Reini Urban
2009-02-22 10:39:18 UTC
Permalink
Post by Andrew Dougherty
Post by Will Coleda
While trying to put the macport for 0.6.1 together, I noticed that the
install failed.
Tracked it down to the fact that --parrot_is_shared=0 seems to be
generating a parrot that relies on a shared lib.
Verified, this still fails[1] as of r36803. This, combined with TT #344,
blocks creation of a functioning macport.
[1] Generates a parrot that depends on libparrot.dylib
That's because Configure.pl doesn't allow you any way to override the
hints file. What I had in mind was a more primitive, ruthless editing of
the darwin hints file, something like this (totally untested)
What I have in mind is a more general conf approach.

1. Disallow $conf->data->set('key') at all if $conf->options->get('key')
exists, only allow $conf->data->add('key').
Users try to fix the wrong hints options, and this is not enforced.
Only some keys are cooperative, most not.

2. Allow all keys to be given at the Configure.pl cmdline as in perl5.
Append (Apply after hints), Undefine and Define.

-Dcc_debug=-g3, -Ulibparrot_static, -Alinkflags=-Wl,--stack,8388608

perl5 Configure:
-D : define symbol to have some value:
-D symbol symbol gets the value 'define'
-D symbol=value symbol gets the value 'value'
common used examples (see INSTALL for more info):
-Duse64bitint use 64bit integers
-Duse64bitall use 64bit integers and pointers
-DEBUGGING=none DEBUGGING options
-Dcc=gcc choose your compiler
-Dprefix=/opt/perl5 choose your destination
-U : undefine symbol:
-U symbol symbol gets the value 'undef'
-U symbol= symbol gets completely empty
e.g.: -Uversiononly
-A : manipulate symbol after the platform specific hints have been
applied:
-A append:symbol=value append value to symbol
-A symbol=value like append:, but with a separating space
-A define:symbol=value define symbol to have value
-A clear:symbol define symbol to be ''
-A define:symbol define symbol to be 'define'
-A eval:symbol=value define symbol to be eval of value
-A prepend:symbol=value prepend value to symbol
-A undef:symbol define symbol to be 'undef'
-A undef:symbol= define symbol to be ''
e.g.: -A prepend:libswanted='cl pthread '
-A ccflags=-DSOME_MACRO
Post by Andrew Dougherty
--- parrot-current/config/init/hints/darwin.pm 2009-02-01 20:44:27.000000000 -0500
+++ parrot-andy/config/init/hints/darwin.pm 2009-02-17 09:55:39.000000000 -0500
@@ -55,20 +55,6 @@
ld_load_flags => '-undefined dynamic_lookup -bundle',
memalign => 'some_memalign',
has_dynamic_linking => 1,
-
- # RT 43147: When built against a dynamic libparrot,
- # installable_parrot records the path to the blib version
- # of the library.
-
- parrot_is_shared => 1,
- libparrot_shared => 'libparrot.$(SOVERSION)$(SHARE_EXT)',
- libparrot_shared_alias => 'libparrot$(SHARE_EXT)',
- rpath => "-L",
- libparrot_soname => "-install_name "
- . $lib_dir
- . $conf->data->get('slash')
- . "libparrot"
- . $conf->data->get('share_ext')
);
}
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Andy Dougherty
2009-02-22 14:14:28 UTC
Permalink
Post by Reini Urban
Post by Will Coleda
While trying to put the macport for 0.6.1 together, I noticed that the
install failed.
Tracked it down to the fact that --parrot_is_shared=0 seems to be
generating a parrot that relies on a shared lib.
Verified, this still fails[1] as of r36803. This, combined with TT #344,
blocks creation of a functioning macport.
[1] Generates a parrot that depends on libparrot.dylib
That's because Configure.pl doesn't allow you any way to override the hints
file. What I had in mind was a more primitive, ruthless editing of the
darwin hints file, something like this (totally untested)
This was intended as a quick hack to try to get something --- anything --
working prior to the 0.9.1 release.
Post by Reini Urban
What I have in mind is a more general conf approach.
1. Disallow $conf->data->set('key') at all if $conf->options->get('key')
exists, only allow $conf->data->add('key').
Users try to fix the wrong hints options, and this is not enforced. Only some
keys are cooperative, most not.
I'm not sure what, exactly, you mean here, but that's ok.
Post by Reini Urban
2. Allow all keys to be given at the Configure.pl cmdline as in perl5.
Append (Apply after hints), Undefine and Define.
See the related discussion in [perl #42412]. (I've updated RT with the
relevant link.)

In any case, I won't have any time to do anything parrot-related for at
least the next several weeks, so I'm afraid I can't be of further help
here.
--
Andy Dougherty ***@lafayette.edu
Loading...