parrot needs a shared library even if configured with --parrot_is_shared=0.

[ghost]

This problem still persists. At least on Linux, running

perl Configure.pl --parrot_is_shared=0

builds a miniparrot that requires a shared libparrot.so.

See [http://rt.perl.org/rt3/Ticket/Display.html?id=53494 Original RT]
for more details.

Originally http://trac.parrot.org/parrot/ticket/1045

[jkeenan]

Slogging through old tickets, tonight I came upon this one. On Linux/i386, I ran:

perl Configure.pl --test --parrot_is_shared=0 --configure_trace

My setting of 0 on that option was duly recorded:

lib/Parrot/Config/Generated.pm:320:  'parrot_is_shared' => '0',
config_lib.pir:222:    set $P0["parrot_is_shared"], "0"

When I ran make, I got a failure here:

./miniparrot -Iruntime/parrot/include config_lib.pir >
  runtime/parrot/include/config.fpmc
./miniparrot: error while loading shared libraries:
  libparrot.so.2.4.0: cannot open shared object file:
  No such file or directory
make: **\* [runtime/parrot/include/config.fpmc] Error 127
/usr/local/bin/perl tools/build/parrot_config_c.pl > \
    src/parrot_config.c
'runtime/parrot/include/config.fpmc' is truncated.
  Remove it and rerun make
make: **\* [src/parrot_config.c] Error 255
Finished

So this seems to me to be more of a build failure than a configuration failure.

In contrast, when I modified my standard configuration command on Darwin/PPC to include this option, I built successfully:

#!/bin/sh
echo "MACOSX_DEPLOYMENT_TARGET is $MACOSX_DEPLOYMENT_TARGET"
CC="/usr/bin/gcc"
CX="/usr/bin/g++"
/usr/local/bin/perl Configure.pl --cc="$CC" --cxx="$CX" --link="$CX" \
    --ld="$CX" \
    --parrot_is_shared=0 \
    --configure_trace \
    $@

So there is something OS-specific going on here.

kid51

[ghost]

So this seems to me to be more of a build failure than a configuration failure.

Fair enough.

In contrast, when I modified my standard configuration command on Darwin/PPC to include this option, I built successfully: [ . . . ] So there is something OS-specific going on here.

It's also possible to get a false success if there's a compatible previously-built libparrot already installed somewhere that will get picked up by the runtime dynamic loader. For example, on Solaris, you can get a false positive by installing a compatible version of parrot and then re-running Configure with the LD_LIBRARY_PATH environment variable set to include the installation directory. Or, you can get the same effect by installing parrot to a place where ldd automatically looks.

I suspect something like that is part of what's happening here.

I'd imagine there is also the possibility for OS-specific issues to arise. Even with --parrot_is_shared=0, the root Makefile still builds both libparrot.a and libparrot.so, and then links against -lparrot. Which one gets used by the link editor in the final compilation step? I don't know that there's any guaranteed unique answer.

[jkeenan]

Replying to doughera:

It's also possible to get a false success if there's a compatible previously-built libparrot already installed somewhere that will get picked up by the runtime dynamic loader.

Today I configured, built and tested Parrot on a Linux box where I know it has never been installed. I got most of the same error as previously reported for Linux.

./miniparrot -Iruntime/parrot/include config_lib.pir >
  runtime/parrot/include/config.fpmc
./miniparrot: error while loading shared libraries:
  libparrot.so.2.4.0: cannot open shared object file:
  No such file or directory
make: **\* [runtime/parrot/include/config.fpmc] Error 127

I did not get the part about config.fpmc being truncated.

Thank you very much.

kid51

[jkeenan]

Re-examining this old ticket tonight, I grepped for parrot_is_shared once I had built parrot without --parrot_is_shared=0. My search excludes files in the configuration system.

$ find . -type f | xargs grep -n parrot_is_shared | \
  grep -vE '(./config/|steps|ports|Configure/Options|Configure.pl|ports|Parrot/Test)'
./lib/Parrot/Config/Generated.pm:338:  'parrot_is_shared' => 1,
Binary file ./runtime/parrot/include/config.fpmc matches
./runtime/parrot/library/distutils.pir:1156:    $I0 = config['parrot_is_shared']
./runtime/parrot/library/distutils.pir:1421:    $I0 = config['parrot_is_shared']
./runtime/parrot/library/distutils.pir:1465:    $I0 = config['parrot_is_shared']
Binary file ./runtime/parrot/library/distutils.pbc matches
Binary file ./src/parrot_config.o matches
Binary file ./src/install_config.o matches
./config_lib.pir:239:    set $P0["parrot_is_shared"], "1"
Binary file ./parrot matches
Binary file ./pbc_to_exe matches
Binary file ./parrot_nci_thunk_gen matches
Binary file ./parrot_config matches
Binary file ./pbc_merge matches
Binary file ./parrot_debugger matches
Binary file ./parrot-nqp matches
Binary file ./ops2c matches
Binary file ./install_config.fpmc matches

Note that while we record a setting for parrot_is_shared we never make reference to that value in any source code files. I would infer from that that the --parrot_is_shared option is (currently) completely irrelevant. And that would explain why we can't build with a 0 setting of it.

Is that inference correct?

kid51