[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: graphics/gegl: fixing MacOS issues
> On Feb 24, 2020, at 4:02 PM, js-pkgsrc%heap.zone@localhost wrote:
> Am 24.02.2020 um 23:58 schrieb Brook Milligan <brook%nmsu.edu@localhost>:
>> Yes, I have since realized the runtime problem, which also occurs with gegl trying to find babl. I did not realize that these programs assume *.so when loading. Is the name of these libraries not buried in the code somewhere? Does it not make more sense to change the name of the file being looked up to preserve the platform-specific norms of *.dylib versus *.so? Did you look into that at all? I’m thinking that other tools would expect *.dylib on MacOS and be fooled by your renaming. But perhaps not.
> I think the opposite is actually the case: Calling them .dylib would be renaming. They were always calling them .so before the migration to meson, it seems. I guess this is similar to Python, which also uses .so and where we also don't rename it.
>> Perhaps you have already considered all this and come to the conclusion that the name switch is the best option.
> I don't have a strong opinion on it, but if upstream is of the opinion that it should always be .so, it seems less troublesome to follow the convention from upstream, even if it's wrong. I mean, .dylib is almost as wrong as .so anyway: Correct would be foobar.bundle/Contents/MacOS/foobar instead of foobar.so / foobar.dylib.
OK, fair point. In any case, I’ll try your explicit renaming on Darwin and see how that fares. Thanks for the pointer.
Main Index |
Thread Index |