Re: [Tigervnc-devel] Build issues in trunk w/ some fixes & suggestions
On Wed, 16 Jan 2013, DRC wrote: If you want, I can see if we can switch our internal FLTK build to CMake instead of Autotools, but I'm not sure what else we can do. Now done. I've also updated BUILDING.txt so that the list of patches is in sync. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689-- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes & suggestions
On 1/16/13 6:56 AM, Peter Åstrand wrote: > The two major sponsors of the TigerVNC project are Cendio and Red Hat, > and we both are focusing on Linux, so it's quite natural that we favour > build systems that works good on Linux. > > Few if any people have the resources to test things on more than a > handful of platforms. We are building and testing TigerVNC for all > supported platforms (Linux, Solaris, Windows, Mac), but with only one > build system (cross compilation under Linux). We are not building on any > version of Windows, Solaris, or Mac OS X. We don't have the resources to > do that. Sorry. > > If you want, I can see if we can switch our internal FLTK build to CMake > instead of Autotools, but I'm not sure what else we can do. That would be helpful, yes. BTW, is Red Hat even using a recent version of TigerVNC? Last I checked, Fedora was still on 1.1.0. -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes & suggestions
On Wed, 16 Jan 2013, DRC wrote: My suggestion is therefore that we start recommending building FLTK with Autotools instead. Ok with everyone? No. Again, goes back to the "eat your own dog food" thing. If you ever actually tried to build TigerVNC on a real Windows platform, you would understand why most things you have done to make it easier on yourself as a Linux developer have made it harder on Windows developers. The two major sponsors of the TigerVNC project are Cendio and Red Hat, and we both are focusing on Linux, so it's quite natural that we favour build systems that works good on Linux. Few if any people have the resources to test things on more than a handful of platforms. We are building and testing TigerVNC for all supported platforms (Linux, Solaris, Windows, Mac), but with only one build system (cross compilation under Linux). We are not building on any version of Windows, Solaris, or Mac OS X. We don't have the resources to do that. Sorry. If you want, I can see if we can switch our internal FLTK build to CMake instead of Autotools, but I'm not sure what else we can do. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689-- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes & suggestions
On 1/16/13 6:08 AM, Peter Åstrand wrote: > On Wed, 16 Jan 2013, DRC wrote: > >> On 1/16/13 3:12 AM, Peter Åstrand wrote: >>> Sure, but we don't have the details. It's not very useful to submit a >>> bug report that says "it fails on some machines but not mine" :-) >> >> Didn't I just supply the details? And a fix? > > Yes, a fix, but I don't understand on which machines this is failing, or > why. (a) Does it matter? A simple examination of the patch reveals that it does the "right thing." If you set CMAKE_REQUIRED_LIBRARIES for the purposes of checking whether a function exists, you should *always* unset it afterwards. (b) OS X, and I don't know exactly why, and I don't exactly care. Probably because libpng isn't in /usr/lib on that platform. All I know is that it failed because the CMakeLists.txt file was not doing the right thing, and making it do the right thing fixed the failure. > Really, it's much better if you communicate with the FLTK upstream > directly. We have no special communication channels. No time to do so, and not my problem. >> Well, if you don't build FLTK with CMake, then why does the documented >> procedure for building FLTK (in BUILDING.txt) require CMake? > > I think this was my mistake. If I remember correctly, I assumed that we > were also building FLTK with CMake and didn't check this. One advantage > though is that it imposes fewer dependencies. For example, if you are > building on Windows, I suppose building with Autotools requires you to > install more packages(?). Don't get me wrong. I'm not suggesting that you switch to autotools. We had that conversation years ago-- autotools is a non-starter for Windows builds. Requiring it as part of the TigerVNC build procedure will eliminate almost all Windows developers from your community. What I am suggesting is that you actually test what you recommend to the open source community. Had you ever tried to build FLTK with CMake on all of the platforms you purport to support, you would have discovered these issues yourselves. > I think it's unfortunate that FLTK is trying to support two different > build systems. My experience is that this never works. Accordingly, I > have opened up http://www.fltk.org/str.php?L2916 . > > Anyway, in the mean time, the question is if we should start building > FLTK with CMake, or if we should change the documentation to recommend > Autotools instead? When looking in the FLTK repository, it seems to me > that the CMake build system gets less attention than the Autotools one, > and is constantly lagging behind. For example, configure.in says we are > at FLTK 1.3.1, while CMakeLists.txt says 1.3.0. There are several bug > reports of that the CMake files are out of sync, for example > http://www.fltk.org/str.php?L2088 . > > My suggestion is therefore that we start recommending building FLTK with > Autotools instead. Ok with everyone? No. Again, goes back to the "eat your own dog food" thing. If you ever actually tried to build TigerVNC on a real Windows platform, you would understand why most things you have done to make it easier on yourself as a Linux developer have made it harder on Windows developers. As far as "everyone", when was the last time anyone but me actually spoke up regarding one of these issues? -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes & suggestions
On Wed, 16 Jan 2013, DRC wrote:
On 1/16/13 3:12 AM, Peter Åstrand wrote:
Sure, but we don't have the details. It's not very useful to submit a
bug report that says "it fails on some machines but not mine" :-)
Didn't I just supply the details? And a fix?
Yes, a fix, but I don't understand on which machines this is failing, or
why.
Really, it's much better if you communicate with the FLTK upstream
directly. We have no special communication channels.
No, because this is a bug introduced by the patches that Cendio made to
FLTK. All I'm suggesting is to extend fltk-1_v6.3.x-keyboard-osx.patch
so that it adds '-framework Carbon' in the CMake build system the same
way it already does in the autotools build system. Don't see why you
have to wait for 1.3.2 for that, since this is not an upstream problem.
It's a problem created by an FLTK patch that was specifically made for
the purposes of TigerVNC.
Ok, that makes sense. Would it be possible for you to extend the patch
in this way? We do not build FLTK with CMake.
Well, if you don't build FLTK with CMake, then why does the documented
procedure for building FLTK (in BUILDING.txt) require CMake?
I think this was my mistake. If I remember correctly, I assumed that we
were also building FLTK with CMake and didn't check this. One advantage
though is that it imposes fewer dependencies. For example, if you are
building on Windows, I suppose building with Autotools requires you to
install more packages(?).
This is the basic problem I've been complaining about all along-- a
fundamental disconnect between what users of the open source code are
expected to do and what Cendio actually tests. In other words, you guys
need to eat your own dog food.
We are working in this direction. Removing the in-tree FLTK version was
one such step. We are not using it, so it constantly got out of sync.
Nowadays, the documentation in BUILDING.txt is directly copied from our
build scripts, and we are documenting and recommending exactly that FLTK
version and those patches that we are actually using.
I think it's unfortunate that FLTK is trying to support two different
build systems. My experience is that this never works. Accordingly, I have
opened up http://www.fltk.org/str.php?L2916 .
Anyway, in the mean time, the question is if we should start building FLTK
with CMake, or if we should change the documentation to recommend
Autotools instead? When looking in the FLTK repository, it seems to me
that the CMake build system gets less attention than the Autotools one,
and is constantly lagging behind. For example, configure.in says we are at
FLTK 1.3.1, while CMakeLists.txt says 1.3.0. There are several bug reports
of that the CMake files are out of sync, for example
http://www.fltk.org/str.php?L2088 .
My suggestion is therefore that we start recommending building FLTK with
Autotools instead. Ok with everyone?
I prefer vncviewer/CMakeLists.txt. In our build, we have actually added
this:
if(UNIX AND NOT APPLE)
# Needed to load icon files
target_link_libraries(vncviewer -Wl,-Bstatic ${FLTK_IMAGES_LIBRARY}
png -Wl,-Bdynamic)
endif()
So add it to everyone's build, then.
We have additional makefile tweaks; we'll need to check if they are
required as well. I'll see if I can find some time for this.
Yes, we should make it as easy as possible. Shouldn't be necessary to
tweak FLTK though; linking libgcc and libstdc++ statically can be done
from the TigerVNC make files.
Try it. I think you'll find, as I did, that it doesn't work that way.
It works in our build system, so I'm sure it's possible. I'm not saying
that it's easy though...
Rgds,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköpinghttp://facebook.com/ThinLinc
Phone: +46-13-214600http://plus.google.com/112509906846170010689--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 ___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes & suggestions
On 1/16/13 3:12 AM, Peter Åstrand wrote:
> Sure, but we don't have the details. It's not very useful to submit a
> bug report that says "it fails on some machines but not mine" :-)
Didn't I just supply the details? And a fix?
>> No, because this is a bug introduced by the patches that Cendio made to
>> FLTK. All I'm suggesting is to extend fltk-1_v6.3.x-keyboard-osx.patch
>> so that it adds '-framework Carbon' in the CMake build system the same
>> way it already does in the autotools build system. Don't see why you
>> have to wait for 1.3.2 for that, since this is not an upstream problem.
>> It's a problem created by an FLTK patch that was specifically made for
>> the purposes of TigerVNC.
>
> Ok, that makes sense. Would it be possible for you to extend the patch
> in this way? We do not build FLTK with CMake.
Well, if you don't build FLTK with CMake, then why does the documented
procedure for building FLTK (in BUILDING.txt) require CMake? This is
the basic problem I've been complaining about all along-- a fundamental
disconnect between what users of the open source code are expected to do
and what Cendio actually tests. In other words, you guys need to eat
your own dog food.
Extending the patch is definitely not a priority for me, but it would
probably take you or Pierre all of 5 minutes.
> I prefer vncviewer/CMakeLists.txt. In our build, we have actually added
> this:
>
> if(UNIX AND NOT APPLE)
># Needed to load icon files
>target_link_libraries(vncviewer -Wl,-Bstatic ${FLTK_IMAGES_LIBRARY}
> png -Wl,-Bdynamic)
> endif()
So add it to everyone's build, then.
> Yes, we should make it as easy as possible. Shouldn't be necessary to
> tweak FLTK though; linking libgcc and libstdc++ statically can be done
> from the TigerVNC make files.
Try it. I think you'll find, as I did, that it doesn't work that way.
--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes & suggestions
On 1/7/13 4:25 AM, Peter Åstrand wrote:
(3) CMakeLists.txt in the FLTK build system needs to be patched as
follows:
Otherwise, it will try to add -lpng to all of the subsequent function
checks, which causes them to fail on some machines (including mine.)
Have you reported this to the FLTK folks? Again, probably makes sense to
wait with further debugging on this until we have 1.3.2.
No, because it's frankly not my problem, and it would be a lot quicker
for you and Pierre, who have inroads into the FLTK project, to report
it.
Sure, but we don't have the details. It's not very useful to submit a bug
report that says "it fails on some machines but not mine" :-)
(4) Fluid build fails on Mac using CMake unless CMakeLists.txt in the
FLTK build system is patched as follows:
As point 3), I think.
No, because this is a bug introduced by the patches that Cendio made to
FLTK. All I'm suggesting is to extend fltk-1_v6.3.x-keyboard-osx.patch
so that it adds '-framework Carbon' in the CMake build system the same
way it already does in the autotools build system. Don't see why you
have to wait for 1.3.2 for that, since this is not an upstream problem.
It's a problem created by an FLTK patch that was specifically made for
the purposes of TigerVNC.
Ok, that makes sense. Would it be possible for you to extend the patch in
this way? We do not build FLTK with CMake.
(6) The TigerVNC build will fail unless I patch TigerVNC's
CMakeLists.txt as follows:
--- CMakeLists.txt(revision 5021)
+++ CMakeLists.txt(working copy)
@@ -265,6 +265,7 @@
if(X11_Xcursor_FOUND)
set(FLTK_LIBRARIES ${FLTK_LIBRARIES} ${X11_Xcursor_LIB})
endif()
+ set(FLTK_LIBRARIES ${FLTK_LIBRARIES} png)
endif()
This goes away when building FLTK with -DOPTION_USE_SYSTEM_LIBPNG=0, but
distribution vendors will run into this problem, since they'll probably
want to use the system libpng. Since the patch above does no harm when
using FLTK's internal PNG library, I would suggest going ahead and
applying it to TigerVNC.
Shouldn't this go into vncviewer/CMakeLists.txt instead?
Effectively, it probably doesn't matter either way, since FLTK is only
used when building vncviewer, but since libpng is a dependency
introduced by FLTK, it made sense to me to include it in FLTK_LIBRARIES.
But either way you want.
I prefer vncviewer/CMakeLists.txt. In our build, we have actually added
this:
if(UNIX AND NOT APPLE)
# Needed to load icon files
target_link_libraries(vncviewer -Wl,-Bstatic ${FLTK_IMAGES_LIBRARY} png
-Wl,-Bdynamic)
endif()
(7) Building FLTK using MinGW is problematic because of the dependency
on the libgcc and libstdc++ DLL's. These dependencies are automatically
Yes, this is somewhat problematic, but as you point out, this is really
a problem with FLTK rather than TigerVNC.
You keep saying that, but I'll say again like I said before-- this is
effectively a regression in the TigerVNC build, because this problem did
not exist in the 1.2 build by virtue of the fact that FLTK was being
built in tree.
Yes, we should make it as easy as possible. Shouldn't be necessary to
tweak FLTK though; linking libgcc and libstdc++ statically can be done
from the TigerVNC make files.
The problem is that Windows has a "convert" executable that's part of
the operating system, but of course it is not the right "convert"
executable. On Linux, if ImageMagick is not installed, the build fails
cryptically with "cannot find /usr/bin/convert" or something like that.
Rather than argue, I checked in a patch (5024) that I have verified to
fix the issue and build correctly on all platforms.
Thanks.
I will now take a look at adjusting the build procedure for FLTK 1.3.2.
Rgds,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköpinghttp://facebook.com/ThinLinc
Phone: +46-13-214600http://plus.google.com/112509906846170010689--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 ___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes & suggestions
On 1/7/13 4:25 AM, Peter Åstrand wrote:
>> (3) CMakeLists.txt in the FLTK build system needs to be patched as
>> follows:
>> Otherwise, it will try to add -lpng to all of the subsequent function
>> checks, which causes them to fail on some machines (including mine.)
>
> Have you reported this to the FLTK folks? Again, probably makes sense to
> wait with further debugging on this until we have 1.3.2.
No, because it's frankly not my problem, and it would be a lot quicker
for you and Pierre, who have inroads into the FLTK project, to report
it. I am assuming that, if you are interested in making the TigerVNC
build user-friendly, you will want to follow these suggestions. I've
already worked around the issues in my own local build. I submitted
these issues to you both as a favor and so users who inevitably try to
build TigerVNC from trunk and come up with the same issues will be able
to google for them. I build TigerVNC only for reference, so I am not
getting paid to solve any broader issues with that code base or with FLTK.
>> (4) Fluid build fails on Mac using CMake unless CMakeLists.txt in the
>> FLTK build system is patched as follows:
>
> As point 3), I think.
No, because this is a bug introduced by the patches that Cendio made to
FLTK. All I'm suggesting is to extend fltk-1_v6.3.x-keyboard-osx.patch
so that it adds '-framework Carbon' in the CMake build system the same
way it already does in the autotools build system. Don't see why you
have to wait for 1.3.2 for that, since this is not an upstream problem.
It's a problem created by an FLTK patch that was specifically made for
the purposes of TigerVNC.
>> (6) The TigerVNC build will fail unless I patch TigerVNC's
>> CMakeLists.txt as follows:
>>
>> --- CMakeLists.txt(revision 5021)
>> +++ CMakeLists.txt(working copy)
>> @@ -265,6 +265,7 @@
>>if(X11_Xcursor_FOUND)
>> set(FLTK_LIBRARIES ${FLTK_LIBRARIES} ${X11_Xcursor_LIB})
>>endif()
>> + set(FLTK_LIBRARIES ${FLTK_LIBRARIES} png)
>> endif()
>>
>>
>> This goes away when building FLTK with -DOPTION_USE_SYSTEM_LIBPNG=0, but
>> distribution vendors will run into this problem, since they'll probably
>> want to use the system libpng. Since the patch above does no harm when
>> using FLTK's internal PNG library, I would suggest going ahead and
>> applying it to TigerVNC.
>
> Shouldn't this go into vncviewer/CMakeLists.txt instead?
Effectively, it probably doesn't matter either way, since FLTK is only
used when building vncviewer, but since libpng is a dependency
introduced by FLTK, it made sense to me to include it in FLTK_LIBRARIES.
But either way you want.
>> (7) Building FLTK using MinGW is problematic because of the dependency
>> on the libgcc and libstdc++ DLL's. These dependencies are automatically
>
> Yes, this is somewhat problematic, but as you point out, this is really
> a problem with FLTK rather than TigerVNC.
You keep saying that, but I'll say again like I said before-- this is
effectively a regression in the TigerVNC build, because this problem did
not exist in the 1.2 build by virtue of the fact that FLTK was being
built in tree. If a user wants to build a workable Windows version of
TigerVNC from trunk, they currently need to seriously hack the FLTK
build system like I did. But whatever. If you want to throw the most
popular client platform under the bus, then that's your decision to
make. Just understand that, the more frustrating you make TigerVNC, the
more you drive users away, and you should ask yourself where those users
are being driven to and why I have such intimate knowledge of their
frustrations with TigerVNC.
>> (8) You are using ImageMagick to generate tigervnc.png. Of course
>> ImageMagick is not available on Windows, so the Windows build fails. I
>> mean, seriously, check the PNG files into SVN. They're all of, what, 2
>> kilobytes?!
>
> I have no objections to checking in the PNG files, but is this really
> enough? Have you tried running the build with the PNG files already in
> place? My guess is that CMake and the make files will still look for
> "convert" etc and fail if it's not available. We would probably need
> some kind of logic that only looks for "convert" if the PNG files needs
> remake.
The problem is that Windows has a "convert" executable that's part of
the operating system, but of course it is not the right "convert"
executable. On Linux, if ImageMagick is not installed, the build fails
cryptically with "cannot find /usr/bin/convert" or something like that.
Rather than argue, I checked in a patch (5024) that I have verified to
fix the issue and build correctly on all platforms. If you don't like
it, back it out. But if you choose to keep using ImageMagick to
generate the icons, then you need to (a) document that as a build
dependency for Linux/Unix platforms and (b) add logic to
media/CMakeLists.txt to ensure that it doesn't try to build the icons on
Windows.
---
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes & suggestions
On Sat, 5 Jan 2013, DRC wrote:
(1) BUILDING.txt needs to be modified to indicate that
fltk-xfixes-xcursor-cmake.2.patch should be applied with patch -p0, not -p1.
Fixed.
(2) It would be much more convenient if BUILDING.txt contained full
links to the patches, rather than links to the page from which they are
downloaded. That way, one could use wget to download them, which is a
more streamlined workflow, since one is building from the command line.
Yes, I guess that would be useful. Right now, however, the plan is to
update to FLTK 1.3.2 as a base. That will get rid of many patches.
(3) CMakeLists.txt in the FLTK build system needs to be patched as follows:
--- CMakeLists.txt (revision 9619)
+++ CMakeLists.txt (working copy)
@@ -167,6 +167,9 @@
endif(LIB_png)
CHECK_FUNCTION_EXISTS(png_get_valid HAVE_PNG_GET_VALID)
CHECK_FUNCTION_EXISTS(png_set_tRNS_to_alpha HAVE_PNG_SET_TRNS_TO_ALPHA)
+if(LIB_png)
+ set(CMAKE_REQUIRED_LIBRARIES "")
+endif(LIB_png)
CHECK_FUNCTION_EXISTS(scandirHAVE_SCANDIR)
CHECK_FUNCTION_EXISTS(snprintf HAVE_SNPRINTF)
Otherwise, it will try to add -lpng to all of the subsequent function
checks, which causes them to fail on some machines (including mine.)
Have you reported this to the FLTK folks? Again, probably makes sense to
wait with further debugging on this until we have 1.3.2.
(4) Fluid build fails on Mac using CMake unless CMakeLists.txt in the
FLTK build system is patched as follows:
As point 3), I think.
(5) When building FLTK, one needs to manually specify
-DCMAKE_BUILD_TYPE=Release if one wants optimized code. Either the FLTK
CMakeLists.txt needs to be modified to make CMAKE_BUILD_TYPE=Release the
default, or it needs to be documented in TigerVNC's BUILDING.txt that
adding this variable is necessary to produce optimized code.
Fixed.
(6) The TigerVNC build will fail unless I patch TigerVNC's
CMakeLists.txt as follows:
--- CMakeLists.txt (revision 5021)
+++ CMakeLists.txt (working copy)
@@ -265,6 +265,7 @@
if(X11_Xcursor_FOUND)
set(FLTK_LIBRARIES ${FLTK_LIBRARIES} ${X11_Xcursor_LIB})
endif()
+ set(FLTK_LIBRARIES ${FLTK_LIBRARIES} png)
endif()
This goes away when building FLTK with -DOPTION_USE_SYSTEM_LIBPNG=0, but
distribution vendors will run into this problem, since they'll probably
want to use the system libpng. Since the patch above does no harm when
using FLTK's internal PNG library, I would suggest going ahead and
applying it to TigerVNC.
Shouldn't this go into vncviewer/CMakeLists.txt instead?
(7) Building FLTK using MinGW is problematic because of the dependency
on the libgcc and libstdc++ DLL's. These dependencies are automatically
taken care of in the TigerVNC build system, but the FLTK build system
doesn't have that same code. It's particularly a problem with MinGW64,
since those DLLs aren't in the PATH, and thus the build will actually
fail because it's trying to run a test program that it just built. It's
problematic in general because, if FLTK depends on libgcc and libstdc++,
so will the TigerVNC executable, which makes packaging it difficult.
This was one reason why it was advantageous to build FLTK in the
TigerVNC tree (it took on the build properties of the rest of the
TigerVNC code.) The only way I was able to hack around the issue was by
copying the BUILD_STATIC code from the TigerVNC CMakeLists.txt file into
the FLTK CMakeLists.txt file. Yuck.
Yes, this is somewhat problematic, but as you point out, this is really a
problem with FLTK rather than TigerVNC.
(8) You are using ImageMagick to generate tigervnc.png. Of course
ImageMagick is not available on Windows, so the Windows build fails. I
mean, seriously, check the PNG files into SVN. They're all of, what, 2
kilobytes?!
I have no objections to checking in the PNG files, but is this really
enough? Have you tried running the build with the PNG files already in
place? My guess is that CMake and the make files will still look for
"convert" etc and fail if it's not available. We would probably need some
kind of logic that only looks for "convert" if the PNG files needs remake.
Rgds,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköpinghttp://facebook.com/ThinLinc
Phone: +46-13-214600http://plus.google.com/112509906846170010689--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.
