2014-12-03 15:39 GMT+06:00 <d.j....@free.fr>:
> >2014-12-02 21:34 GMT+06:00 Konstantin Dmitriev <ksee.zelgadis@...>:
>
> >>
> >>
> >> 2014-12-02 4:06 GMT+06:00 <d.j.a.y@...>:
> >>
> >> I was confident ... i should'nt be ...
> >>>
> >>> You can found (partial) result for master branch (gtk3) in
> >>> https://github.com/d-j-a-y/synfig/tree/djay_gtk3_glibmm24_fixes >>
> >>> I'm not very happy to announce that now we will must ship a
> synfigstudio
> >>> special glib >= 2.42
> >>>
> >>> During my research to resolve the problem, i have found several app
> with
> >>> similar problem... and i finally adopt the MySql way of fixing the
> problem
> >> http://bugs.mysql.com/bug.php?id=74147 >>
> >> If you agree with this way of fixing, i will do the rest of the job
> >>> (keyframe treeview + 0.64.2).
> >>>
> >>>
> >>> Hello, Djay!
> >> Thank you for the investigation and heads up!
> >> Most probably I will be able to bundle glib right into the packages -
> this
> >> will allow to avoid any glib dependency.
> >> Best Regards,
> >>
>
> >OK, I have read the following comment -
> https://bugzilla.gnome.org/show_bug.cgi?id=697229#c29 And here are a few
> conclusions:
> >
> >* It is safe to replace the following line
> > #if GLIB_CHECK_VERSION(2, 42, 0)
> >with:
> > #if GLIB_CHECK_VERSION(2, 37, 5)
> >
> >* Thus, we can lower requirement to glib >= 2.37.5
> >
> >I will try to ship glib 2.35.7 with the packages and test if that would
> >work for our users.
> >
> >Best,
> >K.
>
> Hello here,
>
> 1) Is'nt it requirement to glib <= 2.37.5 ?
>
No. "GLIB_CHECK_VERSION(2, 37, 5)" means glib >= 2.37.5. The code you have
added is compatible with glib >= 2.37.5.
>
> 2) Why do you not want to build right version for right libs? Too much
> work to adapt the building script ?
>
If I will ship glib 2.42, then the package won't work for Linux systems
with glib < 2.42.
> Shipping another lib,
> >From one side, for dev' does that mean we will need to build/install each
> required libs in special path ?
>
Sorry, I don't understood the question.
> >From other side, i think we should prepare all the problematic code for
> the day we up glib (commenting or by inserting preprocessor directive).
>
> And also, will be a problem, if a lib we ship appear to have bugs or even
> worst a security hole .
>
> It's clear, it's a dilemma for us the binary incompatibility we are front
> of .... time to make a choice ...
The choice is made a long time ago. We ship the lowest possible version of
the libs to make sure that it will run on the most variety of systems. We
don't pack every dependency lib into bundle, so we rely on some system
libs. And this is where compatibility should be kept.
With the new Linux build script (in the master branch) I have much more
flexibility, but with 0.64.x branch I am locked with the old build script.
So it puts limitations.
Regards,
K.
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Synfig-devl mailing list
Synfig-devl@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synfig-devl
