Description of problem: The version of ghostscript library /usr/lib/libgs.so.10 shipped with Fedora 38 is not compiled with device support for x11, x11alpha, x11cmyk, x11mono, x11gray2 or x11gray4. No screen is shown when running program linked with libgs the fail with error like: Unknown device: x11alpha Cannot initialize ghostscript engine There is a ghostscript-x11 but programs using the ghostscript library and x11 fail. Version-Release number of selected component (if applicable): ghostscript-10.0.0-3.fc38.x86_64 How reproducible: allways Steps to Reproduce: Compile a program using libgs and open x11 device Actual results: Unknown device: x11alpha Cannot initialize ghostscript engine Expected results: A ghostscript screen. Additional info:
Hi Michael, that is actually upstream decision. With ghostscript-10.0.0: $ gs -h | grep x11 <nothing> In the latest release, -fvisibility=hidden is added into DYNAMIC_CFLAGS. Dynamic device got removed as some symbols became hidden now and only the library is shipped. Using --disable-hidden-visibility could also possibly workaround this. To view postscript files you can use 'gsx' from ghostscript-gtk to view them.
Richard, I asked about this over on the ghostscript-devel list and the answer was ... https://ghostscript.com/pipermail/gs-devel/2023-March/010634.html The problem is that we relatively recently were obliged to start using "hidden symbols" in the build - partly to avoid symbol clashes, and partly because there are security implications not using it. The dynamic X11 drivers rely on private symbols (i.e. symbols that are not part of the public API). Since only API symbols are now exposed, those drivers no longer work. If you *must* use dynamic devices, then you *must* configure with: "--disable-hidden-visibility" And you accept the risks that come with that. Alternatively, drop the "--enable-dynamic" and the X11 devices will be built directly into the .so. The pending 10.01.0 release will error out of configure if "--enable-dynamic" is used without "--disable-hidden-visibility". I confess, I did not realise anyone was using the dynamic device "feature" for real, because it's always been explained to me as a proof-of-concept, included for testing purposes only. Anyway, that's what's going on, sorry for the inconvenience. Chris Why are you now using --enable-dyanamic? I know, not many are using libgs like this but I'm likely not to be the only one. It sounds like there will be a problem with the next gs release if "--enable-dynamic" is used without "--disable-hidden-visibility". Michael
I tried, "--enable-dynamic" with "--disable-hidden-visibility" but it did not make the x11 devices show. When I removed the "--enable-dynamic" flag, the rpmbuild failed 8-( Michael
..do I now also need to link in /usr/lib64/ghostscript/X11.so ?
You need to use gsx. Note that the "make so" build does not produce any "gs": it produces "gsc" and "gsx". So far, we rename "gsc" to "gs". The simplest adjustment to the new order is therefore renaming "gsx" to "gs" instead. I'm confused about the naming anyways: is gsx the gtk build? But I think the main question is why we need dynamic devices at all. If we build without "--enable-dynamic" nor "--disable-hidden-visibility" then both "gsc" and "gsx" will have x11 devices, libgs is even slightly smaller. Besides, that's closer to upstream builds. I tested only locally so far. Feel free to check out distro test builds (fedora spec minus dynamic driver flag) here: https://copr.fedorainfracloud.org/coprs/mjg/ghostscript There is no ghostscript-x11 any more because that (gs) is provided by ghostscript already. Previously, it contained X11.so.
Yes, the copr test build works for me. (libgs contains the x devices)
(In reply to Michael J Gruber from comment #5) > You need to use gsx. > I'm linking a program with libgs (I'm not using the standalone ghostscript)
> Chris Liddell chris.liddell at artifex.com says: > I'm not sure who the current RedHat/Fedora package maintainer is, but if > you can find out and ask them to contact me, I can explain the situation > to them, and possibly come to a solution for packaged version. > > It will need to be resolved when they update to 10.01.0 anyway.
(In reply to Michael Katzmann from comment #9) > > Chris Liddell chris.liddell at artifex.com says: > > I'm not sure who the current RedHat/Fedora package maintainer is, but if > > you can find out and ask them to contact me, I can explain the situation > > to them, and possibly come to a solution for packaged version. > > > > It will need to be resolved when they update to 10.01.0 anyway. I'm sure you reach the right people here :) I'm not sure whether my change is the desired way forward. It implies that libgs depends on libX11.so.6()(64bit) and libXt.so.6()(64bit) now, and avoiding that may have been the reason for the original layout with dynamic devices. OTOH, if we want x11 devices to be supported by libgs, then that seems to be the only safe way as per upstream.
Yes, we don't want to have dependencies on X graphic packages, as it would be undesirable e.g. in a case of GS installation on server. As the dynamic devices cannot be used like before and ghostscript-x11 will be removed I think only option which remains is to change packaging in a way that we have option with and without X11 functionality to meet all needs. I'm going to discuss the possibilities.
How does gsx (ghostscript-gtk) render to the screen ? I couldn't work out from the spec file how the code was built (or what source it was using). (my limited RPM experience 8-( ) gsx does not have the x code but does display a screen so perhaps I can emulate this mechanism in my program using libgs.
FEDORA-2023-c54ac4efef has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c54ac4efef
Rebase to new ghostscript version will have X devices built in directly in library. Since Fedora is primarily desktop OS and few other packages also requires functionality from old ghostscript-x11 this is probably the best solution.
FEDORA-2023-c54ac4efef has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-c54ac4efef See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-c54ac4efef has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.