. I am looking for people to test drive it
and let me know what breaks.
DRC
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applic
Pierre Ossman wrote:
> Note that the 1.0.0 release did not have SIMD acceleration for x86_64,
> so you might want to try checking out a copy from svn. Or building it
> on a 32-bit machine.
It's not necessary to build on a 32-bit machine. You can simply do:
configure --host i686-pc-linux-gnu CF
That's exactly the point. This is an undocumented interface used for
forcing the MMX and SSE code paths on an SSE2-capable system so I can
verify the performance and stability of those code paths. It is not
ever going to be invoked by an end user.
This interface was implemented as a series of en
this at a programmatic level
without exposing the environment variables, but I don't know of a way to
do that.
DRC wrote:
> That's exactly the point. This is an undocumented interface used for
> forcing the MMX and SSE code paths on an SSE2-capable system so I can
> verify
Ruben Kerkhof wrote:
>> I'm afraid the Java stuff isn't properly maintained as it is, so adding
>> another build system is not really interesting unless it comes with a
>> maintainer for it. If you feel up for that, then by all means. :)
>
> Ok, I understand.
> I'll have a look at fixing the Makef
ti...@piments.com wrote:
> Thanks ,
> I pulled trunk but it does not seem to have all the configure and make
> files . I could just copy them across one at a time from 1.0.0 but how
> should I get the proper build structure? What am I missing?
autoreconf -fiv
generates the configure scripts.
ver machine}:{5800+n}
where n is the display number of the VNC server, e.g.
http://myvncserver:5801
Ruben Kerkhof wrote:
> On Wed, Mar 3, 2010 at 01:40, DRC wrote:
>> Ruben Kerkhof wrote:
>>>> I'm afraid the Java stuff isn't properly maintained as it is, so adding
ti...@piments.com wrote:
> > VNC context:
> >
> > All tiger vnc software is run on the remote kubuntu box via ssh from
> > local linux system.
> >
> > r...@local# ssh -C -X -L 5900:localhost:5900 remote.dyndns.info
> > r...@remote:~# vncviewer localhost:0
>
>
> I'm wondering whether runni
I think the patch I just checked into trunk fixes this. Give it a try.
Ruben Kerkhof wrote:
> On Wed, Mar 3, 2010 at 20:58, DRC wrote:
>> It's an applet, not an app. It's designed to be served up by the
>> embedded web server in Xvnc. Try editing the "
ti...@piments.com wrote:
> On 03/03/10 22:31, DRC wrote:
>> ti...@piments.com wrote:
>>> > VNC context:
>>> >
>>> > All tiger vnc software is run on the remote kubuntu box via ssh
>>> from
>>> > local linux syst
...@piments.com wrote:
> On 03/04/10 10:06, DRC wrote:
>> ti...@piments.com wrote:
>>> On 03/03/10 22:31, DRC wrote:
>>>> ti...@piments.com wrote:
>>>>> > VNC context:
>>>>> >
>>>>> > All tiger vnc software is run
On 3/21/10 2:41 PM, Antoine Martin wrote:
>> There are multiple requested features (and bugs) in out tracker, in my
>> opinion
>> those should be addressed in 1.1 release:
>>
>> 1. "Please develop some documentation" (ID 2872352)
>> - such feature is always painful but we should extend our doc a
On 3/21/10 3:14 PM, Antoine Martin wrote:
>> I could write documentation similar to that that I wrote for TurboVNC.
>> Not something I would be able to do for free, though. :(
>>
>> I think the Java applet should work now. I checked in a patch a week or
>> so ago that fixes it.
>>
> Hah, that
I like RST, but it cannot do automatic chapter/section numbering, which
makes it difficult to use for large publications.
On 3/22/10 3:31 AM, Peter Åstrand wrote:
>>> While we're on the subject of documentation, though ... Assuming we did
>>> develop documentation for TigerVNC, what are some idea
ave on the xorg configure line
(--disable-shave), but then it fails as follows:
make all-am
make[1]: Entering directory
`/home/drc/worksrc/tigervnc/linux.75/xorg/xserver/dix'
../doltlibtool --mode=link --tag=CC gcc4 -DHAVE_DIX_CONFIG_H -Wall
-Wpointer-arith -Wstrict-prototypes -Wmissing-
ike to check this in under release/ so I can integrate the
generation of the installer into the pre-release build system.
DRC
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed
On 4/16/10 2:25 AM, Peter Åstrand wrote:
>> config.status: creating Makefile
>> config.status: creating common/Makefile
>> config.status: creating common/os/Makefile
>> config.status: creating common/rdr/Makefile
>> config.status: creating common/network/Makefile
>> config.status: creating common/X
I don't know if this is the same problem, but in TurboVNC, we had
numerous reports of key mapping issues when people were using Gnome as
the window manager. This turned out to be a Gnome bug, and there are a
couple of ways to work around it, but the easiest was to add
export XKL_XMODMAP_DISABLE=1
Adam,
I just spent a significant amount of time improving the Xorg 7.4 build
system in the trunk so that I will be able to provide compatible RPMs to
help users migrate from TurboVNC. Once the final stage of that project
is complete, I will be able to provide binary RPMs and DEBs that we can
rele
If we're reasonably sure that no one is using it, then I don't have any
problems with dropping 1.6.x support in the trunk, particularly since
the "compatible" build scripts do not use it. I don't think it's that
big of a deal to leave it in, however.
On 4/27/10 9:20 AM, Peter Åstrand wrote:
>
>
I don't know if the X server build in general is supposed to work on
non-GCC compilers, but -Wl would certainly fail on anything but GCC, so
I am not comfortable introducing that incompatibility unless the
incompatibility already exists.
It would definitely fail on OS X, but I think there are prob
, which is installed with XCode.
DRC
--
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
This occurs regardless of whether I run configure with --disable-gnutls.
/Users/drc/src/tigervnc/common/rfb/CSecurityVeNCrypt.cxx: In static
member function ‘static rfb::CSecurityStack*
rfb::CSecurityVeNCrypt::getCSecurityStack(int)’:
/Users/drc/src/tigervnc/common/rfb/CSecurityVeNCrypt.cxx:204
On 4/27/10 3:07 PM, Alan Coopersmith wrote:
>> It would definitely fail on OS X, but I think there are probably 50
>> other things in the Xvnc build that would fail first. :) The more
>> relevant question is whether it will fail on Solaris, and I think the
>> answer is "yes" there as well.
>
>
PM -0500, DRC wrote:
>> I can no longer build the trunk on OS X Snow Leopard. When running
>> autoreconf -fiv, I get:
>>
>> configure.ac:80: error: possibly undefined macro: AC_DEFINE
>> If this token and others are legitimate, please use m4_pattern_allow.
&
default.
-- A local version of PKG_CHECK_MODULES should be included in our build
for use on systems that do not provide it.
How to go about doing any of the above is left as an exercise
Yes, in the trunk.
On 4/28/10 5:22 PM, Antoine Martin wrote:
> Hi,
>
> Is building with mingw supported now?
> Last time I sent some patches for building with Visual Studio C++ 2008
> V9, I was told:
>
> "we're going to start building with MinGW
> at some point in the not-so-distant future"
>
>
Additional fuel for this discussion-- the Windows build now fails as
well unless you specify "configure --disable-gnutls".
On 4/28/10 2:53 PM, DRC wrote:
> There are a couple of problems with this, as I see it:
>
> 1) GNU TLS support is enabled by default, so if GNU TLS isn&#
hem that
they don't have GNU TLS.
On 4/29/10 2:03 AM, Pierre Ossman wrote:
> On Wed, 28 Apr 2010 14:53:10 -0500
> DRC wrote:
>
>>
>> I believe that the behavior should be as follows:
>>
>> -- A mechanism other than PKG_CHECK_MODULES should be used to detect
x27;t have time
to argue any more about this. I am checking in a patch to disable GNU
TLS by default, since we all seem to agree on that much at least.
On 4/29/10 2:54 AM, Pierre Ossman wrote:
> On Thu, 29 Apr 2010 02:33:24 -0500
> DRC wrote:
>
>> OK, well, if PKG_CHECK_MODULES
M, Antoine Martin wrote:
> On 04/29/2010 05:59 AM, DRC wrote:
>> Yes, in the trunk.
>>
> Good.
>
> Do you use MinGW on Windows or as a cross compiler on some other platform?
>
> I'm new to mingw (and using it as cross compiler), so I dont really know
> ho
Adam,
My vote would be to go ahead and make these modifications, unless anyone
strongly objects.
> Yes, we can abandon PKG_CHECK_MODULES macro and use AC_CHECK_LIB
> instead. It might be bigger as Pierre said but it will be far more
> compatible. I think that AC_CHECK_LIB is sufficient, no
> AC_C
Works great! Thanks!
On 5/13/10 8:46 AM, Adam Tkac wrote:
> On Fri, May 07, 2010 at 11:35:44AM -0500, DRC wrote:
>> Adam,
>>
>> My vote would be to go ahead and make these modifications, unless anyone
>> strongly objects.
>
> Comm
s code is by using Linux.
In terms of best practices, I don't see any other big open source code
bases using autotools and MinGW to produce Windows executables. I now
know why.
DRC
--
__
On 5/14/10 6:16 AM, Adam Tkac wrote:
> I was able to built TigerVNC with MinGW as well on Windows, btw :) (but only
> with GCC 3.4.5).
You didn't encounter the autotools problem I described?
> I've never compared binaries built with GCC and Visual Studio but after quick
> googling it seems GCC i
On 5/17/10 9:05 AM, Adam Tkac wrote:
> Interesting, this is the first time I hear about a free Visual Studio
> environment. I'm going to test it and if there is no problem with it I
> will reconsider my disapproval of the Microsoft Visual build
> environment. I just wonder how this free version dif
On 5/17/10 9:52 AM, Peter Åstrand wrote:
> Wouldn't it make more sense to fix the problems with MinGW instead? If
> the "official" downloads are bad, we can provide our own
> MinGW-for-windows. Shouldn't be very difficult. Sounds more fruitful
> than trying to maintain multiple build systems.
>
>
I personally find IDE's more of a struggle than command line tools.
Plus, switching to a new IDE would be a lot more trouble than simply
converting and fixing the existing DSP files. Additionally, we'd still
have to use Visual C as the underlying compiler. It's not that building
TigerVNC from the
On 5/17/10 12:18 PM, Peter Åstrand wrote:
>> Per my previous message, there are a lot of additional components
>> required, not just MinGW. We'd have to distribute the necessary MSYS
>> components as well.
>
> MSYS is a part of the MinGW project; not a big problem.
>
>> In total, this would amoun
On 5/18/10 5:35 AM, Adam Tkac wrote:
> I just tested the MS Visual C++ Express 2010 and I have to agree with
> you the "code compatibility" is a valid point. Visual C++ prints bunch
> of stupid warnings, like "hey, this function is not thread safe".
> Seems that non-threaded Windows program is simp
On 5/18/10 10:54 PM, Sir Gallantmon (ニール・ゴンパ) wrote:
> What I don't get is why we're using autotools if our goal is to be cross
> platform. I would have thought that CMake would have been a better option.
>
> Perhaps a better idea would be to replace the buildsystem with CMake and
> make it possib
ot;undefined reference to IID_IActiveDesktop"
I have attempted adding -luuid and -lshell32 to the link line. Those
libraries are where CLSID_ActiveDesktop and IID_IActiveDesktop are
defined in Visual C++.
On 5/14/10 2:35 AM, DRC wrote:
> I suspect that I'm the first person to have ever att
Why reinvent the wheel? I don't see why it's our job to reproduce the
functionality of SSH. Just use SSH.
Now, if you instead mean internal encryption of the RFB protocol stream,
then didn't we get that as a result of the GNU TLS functionality that
Adam added?
On 5/25/10 4:19 AM, Thomas Sonderg
On 5/28/10 4:51 AM, Thomas Sondergaard wrote:
> DRC wrote:
>> Why reinvent the wheel? I don't see why it's our job to reproduce the
>> functionality of SSH. Just use SSH.
>
> Convenience is a good answer. Another answer is that VNC is used for
> many things,
I guess I still don't understand why. "Convenience" seems like actually
the wrong answer here. RFB is not exactly a secure protocol, and I
don't think many SysAdmins would appreciate us opening up a big security
hole to let anyone forward whatever they want by simply getting VNC
access into the m
>> As far as code compatibility, let's start with the fact that MinGW is
>> constantly behind the curve on the Windows API and always will be.
>
> Yes, but it's quite easy to add missing libraries and headers, when
> necessary.
Quite easy? No, far from it. Witness how long it has taken to resol
On 6/1/10 6:52 AM, Thomas Sondergaard wrote:
> Why does it have to be horribly ugly and inefficient? Do you also
> consider the port-forwarding mechanism in ssh to be a horrible ugly
> hack? Other than the large framebuffer update messages causing latency
> problems for other traffic, I don't se
Seems harmless to me. Is this because some of the options are enabling
something rather than disabling something?
On 6/24/10 7:54 AM, Adam Tkac wrote:
> Hello,
>
> vncserver script currently doesn't allow + switches to be
> specified before :X display number:
>
> $ vncserver +bs :1
>
> I would
I'll take a look at this next week and see if I can get SIMD working. I don't
think it's impossible.
On Jun 25, 2010, at 8:04 AM, Adam Tkac wrote:
> Hello,
>
> As I promised in
> http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg00649.html
> thread, I just finished my work o
In the "Build Xorg" section of build-xorg-7.4, can you try adding the
following code?
if [ "${module}" = "pixman" ]; then
extraoptions="${extraoptions} --disable-gtk"
fi
On 7/1/10 2:49 PM, Antoine Martin wrote:
> Hi,
>
> I have seen this one before on another platform (was OSX IIRC), but I
>
Cool. I'll modify the script in the SVN trunk and 1.0 branch.
On 7/3/10 9:08 AM, Antoine Martin wrote:
> On 07/02/2010 03:26 AM, DRC wrote:
>> In the "Build Xorg" section of build-xorg-7.4, can you try adding the
>> following code?
>>
>> if [ "$
EViE was removed in Xorg 7.5. I tried running
./build-xorg init -version 7.5
on my tree and then grepping for evie under xorg/, and I see no
references except in the change logs and such.
That being said, I don't think anyone has successfully built TigerVNC
with Xorg 7.5. I was contracted to a
On 7/8/10 8:32 AM, Adam Tkac wrote:
>> The reason why I didn't want to use vncpasswd is that it is interactive,
>> are there any pure command line alternatives that I can use?
>
> I'm affraid it is currently impossible. However you might temporarily
> use the "passwdInput" patch from Fedora and pa
I would prefer it if the semantics were the same as the legacy vncpasswd
from TightVNC, whereby passing an argument of -f makes vncpasswd read
the plain text password from stdin and output the encrypted password to
stdout. I think that is ultimately more useful, since one could then
use vncpasswd
On 7/8/10 6:56 AM, Adam Tkac wrote:
> Sorry for late response, I was away.
>
> Ah, so you are not connecting to winvnc4 but to Windows RDP server?
> Then, from my point of view, we might consider this as intended
> feature because I can hardly imagine how winvnc4 and RDP server can
> run simulateo
I modified it to behave more like the TightVNC option (whereby short or
blank passwords are silently accepted) and checked it into the trunk.
On 7/9/10 4:09 AM, Antoine Martin wrote:
> On 07/09/2010 12:40 PM, Antoine Martin wrote:
>> On 07/09/2010 06:18 AM, DRC wrote:
>>> I woul
On 7/21/10 3:16 AM, Adam Tkac wrote:
> This is a valid argument but I would like to see feedback from other
> TigerVNC developers to decide which types should be enabled by
> default. I will open a separate thread for this.
I am joining into this discussion late, so I don't think I fully
understan
On 7/22/10 12:27 AM, Martin Koegler wrote:
>> -- A set of "allowed" security types can be configured for the VNC
>> server. It should be possible for a SysAdmin to specify this in a
>> central config file, which will take precedence over command line
>> options or per-user config files (thus, if a
On 7/23/10 3:40 AM, Martin Koegler wrote:
> On Thu, Jul 22, 2010 at 04:02:52PM -0500, DRC wrote:
>> This makes the use of extended authentication types somewhat useless
>> from the point of view of a SysAdmin, though. If there is not a way for
>> them to enforce, or at lea
On 7/26/10 4:43 PM, Antoine Martin wrote:
>> You're missing my point. What I'm trying to do is implement a mechanism
>> whereby the SysAdmin can set global defaults for all TigerVNC server
>> sessions on the system. Yes, there are always ways to hack around this,
>> but the idea is to make it dif
On 7/26/10 6:54 PM, Antoine Martin wrote:
> As someone said, you can bypass the restrictions by downloading other
> Xvnc binaries for your platform of choice. (see rpmfind and others)
> So the restriction is just an illusion of "security", and I worry that
> people may start relying on it.
> Not
No, the patch was checked into the subversion trunk, which is being used
to stage 1.1. It didn't make it into 1.0.1. I just checked in the same
patch to the 1.0 branch, so in case we do a 1.0.2 release, it'll be in
there. In the meantime, you'll probably have to build from source to
get it. I h
>From my point of view, there is still some work I'd like to do related
to getting a pre-release build system set up, which is dependent on
establishing a reasonable solution for building the Windows code (both
server and viewer) -- Step 1 there would be to get SIMD working in the
Visual C++ projec
Can you refresh my memory as to the fallback order of both the
encryption and auth options on the server end, as well as how a user
could configure the server to use only certain encrypt/auth options?
One other question-- does the user/password authentication use the Unix
Login Authentication secu
On 9/2/10 6:37 AM, Adam Tkac wrote:
> I would rather disable "Plain" type by default because it is real
> security hazard. I've commited your patch without "Plain" in the
> default list. User can manually select it.
>
> Rest of the patch is OK, I've commited it as r4127. Thank you very
> much.
I h
On 9/2/10 9:50 AM, Adam Tkac wrote:
> This type is, by default, disabled on the server. It must be enabled
> via commandline parameter (-SecurityTypes). Client has it disabled as
> well but if user specify he wants to use it (and server has Plain type
> enabled) then it is used. If it is client's f
On 9/3/10 12:00 AM, Martin Koegler wrote:
> The client side honors the Security Type order of the server - code
> for using the client side order was removed with "Remove unused
> CConnection::setClientSecTypeOrder function" on Jul 20 2010.
So does that mean if Plain is enabled on the server and p
On 9/2/10 11:53 PM, Martin Koegler wrote:
> After checking, when gnutls_transport_set_global_errno was introduced,
> please decide yourself, if support for older versions is really
> necessary.
I need to try building this stuff on RHEL 4 to make sure it all works on
that platform. I'll try to ge
On 9/4/10 12:34 AM, Martin Koegler wrote:
> The client skips security types, if it is not somewhere in its
> SecurityType parameter.
I guess I will have to build and test it when I'm back in the office,
because I still cannot picture what's going on.
-
It seems as if we're missing common/rfb/UnixPasswordValidator.h, which
is needed to build the Plain sec. type.
g++4 -DHAVE_CONFIG_H -I. -I/home/drc/worksrc/tigervnc/common/rfb
-I../.. -I/home/drc/worksrc/tigervnc/common
-I/home/drc/worksrc/tigervnc/win
-I/home/drc/worksrc/tigervnc/common
On 9/7/10 4:53 AM, Adam Tkac wrote:
> Imagine this situation:
>
> server:
> - admin starts it with following parameter:
> "-SecurityTypes VeNCrypt,Plain,TLSNone,None"
>
> client:
> - started with following parameter
> "-SecurityTypes VeNCrypt,TLSNone,Plain"
>
> In this situation client will
I have confirmed that RHEL 4 doesn't have the
gnutls_transport_set_global_errno function:
g++ -DHAVE_CONFIG_H -I. -I/home/drc/worksrc/tigervnc/common/rdr -I../..
-I/home/drc/worksrc/tigervnc/common
-I/home/drc/worksrc/tigervnc/common/zlib -O3 -static-libgcc -fPIC -Wall
-MT libr
On 9/9/10 2:11 AM, Martin Koegler wrote:
> I can not imaging, how such errors can happen.
>
> This test only adds the following to config.h:
>
> | /* Is gnutls_set_global_errno present */
> | #define gnutls_transport_set_global_errno(A) do { errno = (A); } while(0)
> |
>
> So any code not refe
Once I can successfully get a static build going on RHEL 4 (still having
problems with the lack of gnutls_transport_set_global_errno), I'll look
into these issues. libgcrypt and libgnutls are definitely not
cross-compatible, so the -static switch to build-xorg will probably have
to accommodate tho
On 9/16/10 4:15 AM, Adam Tkac wrote:
> My MinGW patch isn't accepted, yet. And I'm not sure if it will be
> accepted:
> https://sourceforge.net/mailarchive/message.php?msg_name=AANLkTikg0hAGpArLTqFSWn6IdSI5aNOwJk-3ZDl4rqrq%40mail.gmail.com
>
> I'm going to merge my "vcstudio_buildsys" branch to tr
On 9/18/10 4:48 AM, Martin Koegler wrote:
> Autoconf allows adding a argument list to a Macro defined by AC_DEFINE:
>
> | -- Macro: AC_DEFINE (VARIABLE, VALUE, [DESCRIPTION])
> | -- Macro: AC_DEFINE (VARIABLE)
> | Define VARIABLE to VALUE (verbatim), by defining a C preprocessor
> | ma
to be
part of 1.1.
On 9/16/10 4:15 AM, Adam Tkac wrote:
> On Thu, Sep 16, 2010 at 03:14:02AM -0500, DRC wrote:
>> Once I can successfully get a static build going on RHEL 4 (still having
>> problems with the lack of gnutls_transport_set_global_errno), I'll look
>> into th
all? I know this is just my 2 cents but I
> certainly would be willing to help with a SCons based build system.
> What are your thoughts?
>
> Robert
>
>
> On 09/29/2010 03:50 PM, DRC wrote:
>> I've been getting my hands dirty with CMake in recent weeks, and I now
On 9/20/10 3:42 AM, Adam Tkac wrote:
> Which version of autoconf are you using?
The version that ships with RHEL 4 (2.59).
The attached patch seems to make things work properly. Question for
Martin: Is the "while(0)" really necessary? I don't understand why the
macro can't just be:
#define gn
ld system
> either way though. I would love to be able to get it to compile on
> Debian Lenny with one build command though I know Windows is your focus.
>
> Robert
>
>
> On 09/29/2010 05:40 PM, DRC wrote:
>> I've looked at SCons cursorily. The original reason why I
nst
> 7.5 or the git repo. I haven't tried 7.4 since before the TLS stuff was
> officially added. I will try 7.4 again and post my results. Noticed
> the typo in the last email. I meant TigerVNC of course
>
> Robert
>
>
> On 09/30/2010 12:40 PM, DRC wrote:
>
with xorg. It would build part of the dependencies and
> then bomb. All is good with 7.4 using the -static option. After I get
> this tested, I will move on to the Windows build :-(
>
>
> Robert
>
>
> On 09/30/2010 04:34 PM, DRC wrote:
>> The Xorg 7
s clear to everyone at this point why I don't consider
MinGW a viable option for anyone who is actively trying to develop
TigerVNC on a native Windows platform.
On 10/1/10 4:09 AM, DRC wrote:
> The specific errors I see when trying to build with the Xorg 7.5 code on
> RHEL 4
ersion if anyone
>> wants it for testing. I will build the 32 bit version for Snow Leopard
>> later and package it the same. I will try to build under 7.5 on linux
>> later and get you the specific errors I was getting too.
>>
>> Robert
>>
>>
>> On 10/
e compiled 64 bit version if anyone
> wants it for testing. I will build the 32 bit version for Snow Leopard
> later and package it the same. I will try to build under 7.5 on linux
> later and get you the specific errors I was getting too.
>
> Robert
>
>
> On 10/01/2010 05
utput and show it on the
> screen if the program exits with an error for example.
>
> Robert
>
>
> On 10/01/2010 03:43 PM, DRC wrote:
>> I'm not sure if a clickable app is the right approach. The vncviewer
>> code is a Unix/X application that communicates
I see that as a feature, not a bug. We don't want it to be a
free-for-all. We want access controls similar to the subversion repository.
On 10/1/10 4:44 PM, Martin Koegler wrote:
> On Fri, Oct 01, 2010 at 02:38:53PM -0500, DRC wrote:
>> I agree. SourceForge has mediawiki pre
e ultimate deliverable will be an automated build
system that generates binary packages for Linux, Mac, and Windows, and
creating this new Windows build system is a critical prerequisite for me
to start looking at more sexy enhancements to the Windows code, such as
making WinVNC perform decently.
Cendio is going to finance the project, so I will be beginning work on
the new CMake build system within the next week. I need to do some
investigation first to get a feel for how to do cross-compilation, host
detection, feature checking, and other things that will eventually be
necessary when
though, the thought of trying to port over
everything that's in our autotools system all at once makes my head spin.
DRC
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builde
This question is mainly for Cendio, since they are primarily using a
MinGW cross-compiler environment to build TigerVNC for Windows. Is it
necessary to support building WinVNC under MinGW, or would it be
sufficient to simply say that WinVNC can only be built under Visual C++
for now?
pt to generate internationalization files, then
it defeats the purpose of using a cross-platform build tool.
DRC
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for
Yeah, trust me, I scoured the Internet before posing the question on
this list. The issue is that our current i18n system seems to be geared
toward integration with autotools and GNU Make. I can't simply call
Unix commands from CMake, because that wouldn't work in Visual Studio.
If I understood
On 10/27/10 2:08 AM, Peter Åstrand wrote:
> The current i18n system, gettext, should work fine with any build
> system, even though it is probably most often used with Autotools.
OK, so find someone who has successfully implemented it with CMake. You
seem to assume that I haven't already research
What should work:
-- 32-bit and 64-bit builds using NMake (with Visual C++ 2005-2010),
Visual Studio 2005-2010 IDE, or MinGW/MinGW-w64 (either native or
cross-compiled on Linux.)
-- WinVNC, if built with Visual C++. The default is currently to
disable the WinVNC build when using MinGW, but you c
On 10/27/10 8:04 AM, Peter Åstrand wrote:
> I think you should take a look at the Scribus project and how it
> supports CMake. From what I can tell at a quick glance, checking for
> "various characteristics of Unix systems" is very straight forward: In
> scribus-1.3.3.14/ConfigureChecks.cmake:
>
>
Please post log. I think I was the one who made that change.
On Oct 29, 2010, at 1:52 PM, Robert Goley wrote:
> The changes made to configure.ac after revision 4128 have broken the checks
> for gnutls on Debian 5.0 (Lenny). Using the version from 4128 works
> perfectly. Wanted to let everyon
o SVN.
On Oct 29, 2010, at 8:01 AM, Adam Tkac wrote:
> On Wed, Oct 27, 2010 at 03:16:58AM -0500, DRC wrote:
>> What should work:
>>
>> -- 32-bit and 64-bit builds using NMake (with Visual C++ 2005-2010),
>> Visual Studio 2005-2010 IDE, or MinGW/MinGW-w64 (either
On 11/2/10 10:58 AM, Antoine Martin wrote:
>> "--disable-config-hal" and "--disable-config-udev" configure options should
>> fix
>> those issues.
> Would you recommend that hal and udev be turned off for a default
> generic build? Or is it a harmless error?
> I don't really see much point in havin
On 11/2/10 8:33 AM, Robert Goley wrote:
>>> After more testing, I was able to get it to compile. It does not
>>> seem to have TLS support enabled so I will have to look into why
>> TLS support requires GNUTLS library and we still don't adapted our
>> Windows build system to use it, unfortunately.
1 - 100 of 618 matches
Mail list logo
