Re: [wx-dev] GNOME printing now based on wxDynamicLibrary
Vaclav Slavik
Vadim Zeitlin wrote:
> Exactly, thanks a lot for doing it (looking forward to trying it
> myself as soon as I have a Linux system to built on again...)! How
> did you solve the problems mentioned by Vaclav in another message,
> mainly the one with the library name which can be different in
> different distributions?
That's by far the least important one (because the least likely to
happen)... Short answer is, Robert didn't address it (it would be
impossible to, he must have nearly finished it by the time I posted).
The name is hard-coded ("libgnomeprint-2-2.so" and
"libgnomeprintui-2-2.so"). Note that there are additional problems
with this:
a) This _will_ break as soon as you try to compile it against the next
binary incompatible GNOME version that uses different name (i.e. no
"2-2" substring in the name).
b) This _will_ break if the application is compiled against, say,
libgnomeprint-2-2.so.0, but runs against libgnomeprint-2-2.so.1; the
app would normally refuse to run in such situation, but runs all
right now.
c) Finally, this does only work on development machines: .so files are
part of -devel packages that are very often not instaled. I didn't
mention this in my previous post simply because I thought it's
obvious, sorry for the omission.
What exactly is the reason to not do this in the way SDL wxWave
backend does it? I.e. there's a dynamically loadable plugin that
links against the required libraries "normally". This avoids all the
problems with dynamic linking (the only thing that you cannot do is
to LD_PRELOAD parts of wx's plugin itself, and that can be addressed
by providing a way to use user's own plugin dir).
Regards,
Vaclav
--
PGP key: 0x465264C9, available from http://pgp.mit.edu/
Vaclav Slavik
> > a) This _will_ break as soon as you try to compile it against the
> > next binary incompatible GNOME version that uses different name
> > (i.e. no "2-2" substring in the name).
>
> otherwise whereas with the code in place, it would fall
> back to the old printing code.
Sorry, but this is just wrong. The app would *NOT* crash if it
was compiled against headers of a new GNOME version (say, 3.0). With
your approach, application compiled against this hypothetical GNOME
3.0, which would work just fine when compiled and linked normally
(because it would use the right headers and libs), would *never* work
at all if you hardcode the library version like this. This approach is
more or less fine if all you consider is present moment, but it's not
future-proof at all.
Robert Roebling
> > The disagreement is over your claim that the current
> > implementation will crash at runtime (it may fail to
> > load, it won't crash)
>
> Sorry, but this is wishful thinking. As soon as libgnomeprint-2-2.so
> symlink points to anything other than libgnomeprint-2-2.so.0 (and the
> possibility of this is exactly the reason why shared libs are
> organised the way they are on Linux), a crash becomes very real
> possibility
Of course, anything can go wrong, but this
http://developer.gnome.org/dotplan/api_rules.html
means that "GNOME developers platform" should be ABI
stable until a major version change. If the ABI interface
unintentionally changes without a change in the version,
then the app will crash or not load at all whatever way we
load the library. I still don't see any situation where the
approach using wxDynamicLibrary would crash whereas
it would work correctly when using normal linking.
Robert