On Thu, Oct 31, 2013 at 6:13 AM, Pierre Ossman <oss...@cendio.se> wrote:

> On Wed, 30 Oct 2013 16:10:12 -0500
> DRC <dcomman...@users.sourceforge.net> wrote:
> > The PNG issue is one I've pointed out on the tigervnc-devel list before,
> > but the TigerVNC developers have not accepted my fix for some reason.
> > The patch to fix it is attached
> > (0001-Link-vncviewer-with-libpng-this-avoids-a-build-error.patch).
> >
> Because that patch is not needed when you build things the "normal" way.
> vncviewer will depend on libfltk.so, which will resolve it's own need of
> libpng.so. The problem appears because you're trying to link FLTK
> statically. This is not a method that is particularly well supported
> with today's development tools.

I don't follow you here.  By "normal" do you mean foregoing the advanced
features of the viewer that depend on the patched fltk and dynamically
linking against the distribution supplied libfltk.so?  Short of replacing
the system libfltk.so, I don't see a reasonable way to build a dynamically
linked viewer with all the bells and whistles.

> Still, this is something that has been bothering me. So although I
> think we should recommend linking dynamically as the "official" way, we
> could see if we can make it easier to hack together a static build.
> Perhaps provide examples for certain configurations.

I think that most people that have chosen to incorporate the patched fltk
would link it statically, and in order to make anything portable
(particularly for platforms that don't natively have fltk) you pretty much
have to.  I don't have any dogmatic objections to building against the
patched fltk, I think the features are well worth the overhead.  It's
unfortunate that Fltk has not accepted so many of these patches after all
this time and I'm not sure what needs to happen before they will.

So here's my suggestion:

Add a 'contrib' directory to the trunk and in it keep a copy of not only
the most current build recipes, but also distribution-specific packaging
scripts, patches, etc.  I know that there is already a buildscripts
directory, we could alternatively update that but I would like to see it
under the trunk for packaging convenience.  This at least archives the
patches that are necessary to build on certain platforms and provides some
additional templates for people that wish to build from source.  I'm OK
with taking responsibility for this if no one objects.

Also, we should probably migrate this discussion to the devel list.

Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
Tigervnc-devel mailing list

Reply via email to