Can't build a well-behaved Rakudo RPM without being able to specify system library paths

[wayland]

See attached patch; it may not be the only way to do it, but it shows the kind of thing that's needed. In the short term, it can be worked around by using LD_LIBRARY_PATH.

[wayland]

Do I need to do anything else to help this patch along?

[doughera]

It might help to explain the problem and how this is an appropriate solution. The only documentation I see is in this addition to the --help menu:

-S add path to system library search\n" 

but, to my untrained eye, this doesn't look significantly different from the existing switch

-L add path to library search\n"

[wayland]

Sorry, I assumed that this code would be reviewed by someone who'd probably written the original. I'll see what I can do to explain.

Parrot has three paths internally. These are the Include path, the Library path, and the Dynamic Extensions (system libraries) path. The first two of these have an option to change them (-I and -L, respectively). You'll notice that case 'S' adds to PARROT_LIB_PATH_DYNEXT, just as case 'L' above it adds to PARROT_LIB_PATH_LIBRARY, and case 'I' (which doesn't appear in the patch, but does appear in the C file) adds to PARROT_LIB_PATH_INCLUDE.

I forget now why I needed this (I'll add more information if I come across the reason again), but it seems to me that parrot is designed to be compiled with its files in specific locations, and these are not the locations that RPM wants them to be. With the -S switch, you can help parrot find the files it needs.

There may be a better way of trying to resolve my specific problem, but I think it's a good idea in general to allow people to add to the system library path; if I wanted to do it, others may also have a legitimate reason for this.

Actually, one more thing has come back to me. I initially solved this problem by altering the LD_LIBRARY_PATH in my Unix environment, but was under the impression that this is generally considered a bad thing, and I thought this alternative was better. So I have the impression that -L on parrot does the equivalent of gcc's -L, but for Parrot files. But that means that we don't have a way to do it for actual libraries. That's what this is trying to fix.

I do remember that I got one step closer to a working Rakudo RPM doing this. I've disassembled my working parrot RPM to try to construct separate patches for the issue(s) I'm trying to resolve. If the other ones get solved first, then I'll no doubt run across this problem again and be able to give more specifics.

Anyway, I hope the information I've provided helps some. Please ask more questions if useful.

[doughera]

Thank you for the nice explanation. I had looked in docs/running.pod to try to understand the purpose of these command-line options. Silly me. (Calling it a "system library path" instead of the "dynamic extensions path" also confused me.) I do not know what specific RPM problems you encountered, but there might be other ways around those problems.

Anyway, yes. I see your point that if there are three different paths, then parrot indeed needs three different options.

However, while those options ought to be available, they also ought not to be necessary for this case.

You ought to be able to configure parrot to put things where you want them in the first place. There ought to be appropriate Configure.pl command-line options to set each of those three paths independently.

[wayland]

Hmm. Ok. I would expect that the files will be getting moved there at the "make install" stage of things. But we can tell the specfile where that will be, and that shouldn't be a problem.

So does that mean that we can apply this patch?

[allison]

I've applied a modified version of the patch in r38094. This changes the name of the option to -X instead of -S (as a better representation of "dynamic eXtension"). It also adds long form versions of the options as --include, --library, and --dynext.

I'm closing this ticket. Other discussion about install locations should go in a separate ticket.