So why didn't you report this? I cannot found anything about this,
neither in the tracker nor on the mailinglist. The patch apparently
worked fine for Adam and it worked fine for us.
I mentioned it several times on the list, in the context of our
discussions regarding moving to CMake for Windows, regarding the
autotools performance problem on Windows, etc.
I've done a gmane search for libuuid on the tigervnc-devel list. No
matches, except for this thread, and an email I wrote myself about another
thing.
Don't know how the patch could have possibly worked fine, since it did
not apparently add anything to the link libraries--
Yes, it does. It patches shell32.c, which is used to build libshell32.a.
or, if it did, that portion was apparently not accepted by MinGW.
As far as I understand, nothing at all has been accepted by the MinGW
project. Don't know anything about MinGW64 though.
Well, curiously, apparently that patch made it into MinGW64, and I just
tried again with that compiler-- same result. Compiles but does not
link, because the stub is not in libuuid.
Never heard of such a problem. Can you please give us the technical
details? Which missing symbol, which error message...
Why don't you try building it on a recent version of MinGW64 (it's
probably reproducible using MinGW64 for Linux) and see for yourself?
We do not have a MinGW64 installation at hand, but I'll put this on my
TODO list.
When we had this discussion before, we discussed the fact that they had
rejected the patch, but apparently they did eventually accept the header
portion of it.
You are talking about MinGW64, right? These are 2 different projects.
(Not sure if you know about it, but both MinGW and MinGW64 provides both
32- and 64-bit toolchains. This is somewhat confusing.)
Interestingly, your new patch to libos does work with MinGW32, but now
it interferes with the broken patch in MinGW64.
How does it interfere? Please give us the technical details.
Doesn't compile. The headers interfere. Again, try it for yourself.
If you have a working MinGW64 installation, we would save time if you
could just try this and post the result.
MinGW contains most of the Win32 functionality one needs. Especially if
you want to keep supporting older versions of Windows, which I suppose
we want. We don't want a WinVNC or vncviewer which only works on Windows
7+. I thought you had the same goals, since you have been working on
supporting platforms such as RHEL4?
Peter, you have a real talent for twisting words around. Supporting
Windows 7 does not mean that the code only works on that platform. It
means that, perhaps, it may be necessary to conditionally use APIs on
that platform to make WinVNC work properly. Then again, maybe that
platform can be supported via simple bug fixes. Until WinVNC is working
You have a point, but it's also nice if the functionality is not too
different between WinVNC on, say, XP and Win7.
Just as a for-instance,
DEFINE_GUID(CLSID_ActiveDesktop,0x75048700L,0xEF1F,0x11D0,0x98,0x88,0x00,0x60,0x97,0xDE,0xAC,0xF9);
DEFINE_GUID(IID_IActiveDesktop,0xF490EB00L,0x1240,0x11D1,0x98,0x88,0x00,0x60,0x97,0xDE,0xAC,0xF9);
is not anywhere in the MSDN documentation and, in fact, appears to have
been pretty much blindly copied from the Microsoft header files.
Apparently, you haven't read through the MinGW Sourceforge tracker item
about this issue. Then you would have known that Adam was using a short C
program to retrieve the values.
Sure, not as easy as reading MSDN, but then again, this is an exception.
I am certain that the MinGW Project has discussions regarding potential
dangers of IP infringement whenever new interfaces are added, and I know
they discussed such things in the context of the ActiveDesktop patch.
I would be uncomfortable putting new, non-obvious Win32 interface code
into TigerVNC without a similar vetting process, and our project is
really not in the position to do that vetting.
MinGW has an unusually strict policy. MinGW64 is more relaxed. If
definitions are accepted by MinGW64, this is good enough for me.
What's the problem? Writing CMake (or Autotool) tests is the standard
approach when using functionality that is not guaranteed to work on all
platforms. This is the approach we are using for UNIX as well, remember.
You're confusing the issue, Peter. When we write "platform" checks,
"platform" typically means a particular O/S configuration. Few people
would be on board with, for instance, depending on a particular piece of
functionality in GCC that was broken in some releases.
GCC is not a good example; missing headers & libs doesn't have anything to
do with GCC.
Checking for the necessary libs & headers is actually a pretty common
thing to do in UNIX. In the Windows world this is not as common, since in
practice everybody are always using the MS SDK and you can often get away
with checking versions rather than functionality.
Having to try every simple change with two different toolchains is worse.
It's actually quite simple to do if you have a real Windows machine.
However, since you don't, that is why I proposed a compromise.
We have many Windows machines. Still we think it's a bad idea to require
one to be able to develop.
Enterprise-quality software is not built by hacking.
"Enterprise" means different things to different people. Very often it
is not a positive thing. Take a look at
http://thedailywtf.com/Articles/The-Enterprise-Dependency.aspx (or
search for other Enterprise articles) and you'll see what I mean.
http://www.cendio.com/products/thinlinc/
"Cendio is an enterprise software company offering a Terminal Server
solution to enable Server Based Computing."
You need to be able to adapt your language to the audience. Many decision
makers likes to hear the E word, and they do not object to sales persons
wearing tuxedos. But if one developer tried to convince me of a certain
toolchain by dressing up, well, that would have the opposite effect on
me... :-)
So in the open source meritocracy, "enterprise" may very well be a bad
thing and "hacking" something positive. In this context, it's easier to
impress somebody by, say, showing a Linux kernel commit, rather mentioning
that one have worked for a Fortune 500 company.
For me, it doesn't have *anything* to do with "feeling uncomfortable".
It's about selecting one toolchain that does the work; supports all of
our platforms. If Visual Studio could run under Linux and generate
binaries for Linux, Solaris, OS X etc, then we could discuss getting rid
of MinGW. But that won't happen.
Peter, it *doesn't* do the work, not without lots of *hacking*.
We think differently.
The fact that you would even recommend building *Mac* software on a
*Linux* platform proves my point. Who does that? Certainly no one
building Mac software professionally.
If you look at the embedded world (including mobile devices with Symbian
and Android), cross compiling is the standard approach; typically the only
supported configuration. If you think of it, every professional Mac
software vendor which builds fat binaries (ie containing both PPC and x86
code) are also cross compiling. So this principle is in no way "strange"
or "unprofessional". Sure, the exact combination of building OS X binaries
on Linux might not be as widespread, even though there are many great
tutorials about it on the net. But it's still a very powerful and
professional approach. We are using GCC as well as Apples headers & libs,
so this build environment is not that different from that on a native Mac.
So basically, what you're saying is that everyone who wants to work on
our code needs to have a Linux machine?
No, this is not what I am saying.
Most people who develop Windows code use a Windows machine, and most
people who develop Mac code use a Mac machine. We need to support those
people. This is not just Cendio's baby.
Of course not. That's why MinGW is so great, because it runs so well on
both Windows and Linux.
For Mac, Apple ships GCC, so developers can choose if they want to cross
compile on Linux (or any platform), or build natively. We do not want to
exclude anybody.
My assumption is that Cendio isn't going to ever do the right thing and
set up a Windows machine for dev testing, so the compromise is that you
guys keep doing what you've always done, but since you're not going to
test VStudio, I want to minimize the damage potential by minimizing the
code that is built with VStudio. Thus, I move WinVNC into a sub-build,
and that way, most of the stuff you work on regularly, such as FLTK,
doesn't need to be supported on VStudio any longer.
This sounds good. If I understand you correctly, this is certainly a step
in the direction we want. Please post a suggested patch.
We can start with making sure WinVNC works with MinGW. If you have no
objections, I'd like to commit the patch.
I have strong objections, since the patch breaks MinGW64.
I'd like to resolve that problem. If you can provide us with details, that
would be great. Otherwise, I'll try to look at the problem myself.
Why are you so focused on this, Peter? I didn't think Cendio cared
about WinVNC.
We care about the entire TigerVNC project. WinVNC is an important
component for more widespread use of TigerVNC. I regret that we do not
have any resources to work on it, but we appreciate any contribution.
Also, the issue of which toolchain(s) should be supported is of course a
very important question that affects the entire project. I think it's
important to take some time to discuss this.
Rgds,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
