Ticket #1279 (closed bug: fixed)

Opened 12 years ago

Last modified 12 years ago

Parrot prefers libraries in build tree to installed tree or current directory.

Reported by: pmichaud Owned by:
Priority: major Milestone:
Component: install Version: 1.7.0
Severity: high Keywords:
Cc: Language:
Patch status: Platform:


When executing load_bytecode 'foo.pbc', if foo.pbc exists in runtime/parrot/library of Parrot's build location, then that library is loaded in preference to any other copy of the library that may exist. This is true even for installed parrots -- the build tree version gets prioritized over any installed library of the same name, or any same-named library in the current working directory.

IMO, an installed Parrot (parrot executable created via "make install") should look only in the current directory and in the installed library path (in that order), and never search the build tree path.


Change History

Changed 12 years ago by chromatic

  • status changed from new to closed
  • resolution set to fixed

Agreed. I believe r42590 fixes this. If not, feel free to reopen.

Changed 12 years ago by fperrad

$ perl tools/dev/mk_language_shell.pl SomeLang
$ cd somelang
$ parrot Configure.pir
Hello, I'm Configure. My job is to poke and prod
your system to figure out how to build Xyz.

Could not find non-existent sub genfile

that fails because in somelang/Configure.pir, the instruction

load_bytecode 'Configure.pbc'

reload somelang/Configure.pir itself instead of runtime/library/Configure.pbc.

Changed 12 years ago by fperrad


[23:05]	<fperrad>	chromatic, could you look at my comment in TT #1279 and confirm if it's a bug or not.
[23:05]	<fperrad>	If not a bug, I just rename my library.
[23:05]	<chromatic>	Will do.
[23:06]	<chromatic>	It's working as designed right now, but it's easy to argue that it's surprising.
[23:06]	<chromatic>	The easiest solution is to rename your library.

Changed 12 years ago by fperrad

renamed in r42833

Note: See TracTickets for help on using tickets.