Skip to content

"Failed to load libpcre" during build #302

colomon opened this Issue May 12, 2011 · 14 comments

7 participants

colomon commented May 11, 2011

2801 byte attachment from colomon

Summary: "Failed to load libpcre" during build
Reported by:
Using RELEASE_3_3_0-199-g3b374ae, I get the following (under OS X):

Failed to load libpcre
current instr.: 'parrot;PCRE;init' pc 0 (runtime/parrot/library/pcre.pir:57)
called from Sub 'read_one_sig' pc 1943 (tools/dev/nci_thunk_gen.pir:854)
called from Sub 'read_sigs' pc 1864 (tools/dev/nci_thunk_gen.pir:816)
called from Sub 'main' pc 40 (tools/dev/nci_thunk_gen.pir:48)
gmake: *** [src/glut_nci_thunks.c] Error 1
Command failed (status 512): gmake install-dev
Error while executing perl build/ --prefix=/Users/colomon/sol/temp/rakudo/parrot_install --gc=gms --optimize; aborting

I've been successfully building Parrot this way for years, so this would appear to be a fairly recent change. Scuttlebutt on #perl6 is that other people have seen this problem as well.

osname= darwin
osvers= 9.0
arch=   darwin-thread-multi-2level
cc=     cc
Summary of my parrot 3.3.0 (r1) configuration:
  configdate='Wed May 11 18:47:17 2011 GMT'
    osname=darwin, archname=darwin-multi-2level
  Linker and Libraries:
    link='c++', linkflags='-undefined dynamic_lookup -L/opt/local/lib',
    ld='c++', ldflags='-L/opt/local/lib -fstack-protector -L"/Users/colomon/sol/temp/rakudo/parrot/blib/lib"',
    libs='-lm -lutil -lgmp -lreadline -lintl'
  Dynamic Linking:
    cc_shared=' ',
    link_dynamic=' ',
    ld_share_flags='-dynamiclib -undefined dynamic_lookup',
    ld_load_flags='-undefined dynamic_lookup -bundle'
    o='.o', a='.a', exe='',
    share_ext='.dylib', load_ext='.bundle'
  Misc Programs:
    ar='ar', ranlib='ranlib',
    make='gmake', make_set_make='#'
    iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
    ptrsize=4,  byteorder=1234, 
    nv=double, numvalsize=8, doublesize=8, longdoublesize=16

    DYLD_LIBRARY_PATH =:/usr/local/netpbm/lib
    HOME =/Users/colomon
    LANG =en_US.UTF-8
    LANGUAGE  (unset)
    LC_CTYPE =en_US.UTF-8
    LD_LIBRARY_PATH  (unset)
    LOGDIR  (unset)
    PATH =/Users/colomon/.perl6/bin:/opt/local/bin:/opt/local/sbin::/Users/colomon/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/opt/local/bin:/usr/local/git/bin:/usr/local/netpbm/bin
    SHELL =/bin/bash
Parrot Virtual Machine member
tadzik commented May 12, 2011

I have the same problem (linux, amd64), worked around it using --without-pcre as a build parameter.

colomon commented May 12, 2011

I should have said that I worked around it the same way.

jkeenan commented May 12, 2011

Could I ask that this ticket be evaluated in consideration with these currently open tickets that appear to touch on PCRE?

TT #2028

TT #2024

TT #1795

Thank you very much.


jkeenan commented Jun 29, 2011

Additional PCRE-related build failure reported today: output

 make output

moritz commented Aug 2, 2011

MvG++ posted a patch at -- somebody please review and apply it.

Parrot Virtual Machine member

merged in 2d6e52a, test welcome

jkeenan commented Aug 12, 2011

Replying to jimmy:

merged in 2d6e52a, test welcome

Would it be possible for you to write such a test?

Thank you very much.


Parrot Virtual Machine member
leto commented Dec 12, 2012

Can anybody comment on the status of this issue?

jkeenan commented Dec 13, 2012
  1. Tonight I installed pcre on a Darwin/Intel box where it was not previously installed. I used 'homebrew' and it installed pcre version 8.31 -- though, curiously, reported finding version 8.02. Nonetheless, 'make' proceeded without incident and the only failure in 'make test' was that in 'ext/nqp-rx/t/nqp/46-charspec.t' that has previously been reported.

  2. Some time ago I installed PCRE on my Linode. reports finding version 7.6 and this has not posed any 'make' or 'make test' problems in a long time.

@rurban rurban was assigned Dec 27, 2012
Parrot Virtual Machine member
rurban commented Dec 27, 2012

Fixed on gentoo
Tried ok on win32-gcc and my linux and darwin boxes (never failed there)

Still failing on my failing darwin/ppc box with macports, because /opt/local/lib is in the gcc libsearch path and
-L/opt/local/lib was added by hints so the conf probe passes, but is not in the parrot loadlib search path,
nor the ld loader path, so Parrot_dyn_load_lib fails.

Parrot Virtual Machine member
rurban commented Dec 27, 2012

I'll add a new dynext_libs config entry, a env_search_path_sep seperated list of lib paths,
filled by hints (later maybe by a commandline option) - for now only by fink and macports -

and add these libs if not empty to the PARROT_LIB_PATH_DYNEXT. Otherwise the runtime will never know that the build system used a proper libpath.

See branch rurban/pcre-dynext_libs-gh302

Parrot Virtual Machine member
rurban commented Dec 27, 2012

Fixed with f1f4f4e

@rurban rurban added a commit that referenced this issue Jan 2, 2013
@rurban rurban [GH #302] new config dynext_libs, new ENV var PARROT_DYNEXT, new add_…

On some systems a special library dir is in the cc library search, or added by -L to the libpath
but this path is missing from the loader configuration, so runtime dlopen attempts will fail.
Most prominently pcre on macports or fink, missing /opt/local/lib.
Hints may add a new key dynext_libs to add such a path to DYNEXT for loadlib.
Also provide a new PARROT_DYNEXT to manually set such paths for the runtime.
Add a helper function add_env_paths() to add multiple paths from an enviroment variable
to some library search path. Currently PARROT_INCLUDE and PARROT_LIBRARY only accept one path element.
(See #903)
@rurban rurban added a commit that referenced this issue Jan 2, 2013
@rurban rurban [GH #302] special windows fixes, path_guarantee_trailing_separator
windows adds ./ to dynext to be explicit about the windows loadlib order (which does this)
Ensure trailing_separator during configuration and init.
@rurban rurban added a commit that referenced this issue Jan 2, 2013
@rurban rurban [GH #302] reword last test 2e3af84
Parrot Virtual Machine member
rurban commented Jan 2, 2013

Fixed with fa14122, the merge of rurban/pcre-dynext_libs-gh302

dynext_libs subsequently renamed to dynext_dirs

@rurban rurban closed this Jan 2, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.