# New Ticket Created by "Yehoshua Sapir" # Please include the string: [perl #42861] # in the subject line of all future correspondence about this issue. # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42861 >
This has a lot to do with tickets #42558 and #34994: (there's quite a bit to read in both) http://rt.perl.org/rt3/Public/Bug/Display.html?id=42558 http://rt.perl.org/rt3/Public/Bug/Display.html?id=34994 To get to config.fpmc (which is in runtime/parrot/include/), config.pir gets Parrot's runtime prefix via interpinfo .INTERPINFO_RUNTIME_PREFIX (this is part of patch #42558) and then adds "/runtime/parrot/include/config.fpmc" onto it. This works for an uninstalled Parrot, as the runtime prefix returned is the Parrot root directory, where runtime/ lives. On my machine, an installed Parrot returns "/usr/local" for the runtime prefix, while the installed config.fpmc lives in /usr/local/lib/parrot/include/ . So config.pir tries to look at /usr/local/runtime/parrot/include and fails. That was the bug report, my conclusions from here onwards :) If the "runtime" directory gets installed to "/usr/local/lib", (or whatever) then I think that for an installed Parrot that should be the runtime prefix. I'm guessing there's some reason that /usr/local is returned here instead. As far as I can tell, the only place that the runtime prefix is used in the Parrot code is Parrot_locate_runtime_file_str (in library.c) where it's used to prefix the library paths from parrot_init_library_paths (same file). That function returns both options - both runtime/ and lib/, so it works in both situations, but it seems to me it would be better to figure it out according to the real location of the runtime. Also, the runtime prefix is stored in the interpreter's IGLOBALS_CONFIG_HASH under the key "prefix". I think it would probably be better to rename that to "runtime_prefix".
