Ok, this may not be interesting to anybody but myself. I searched online for the error messages I received and came up with nothing. So I wanted to post it on the off-chance someone else had these problems, or that I might go braindead and forget at some point in the future.

For reference, the system I built this on was an LFS 6.0 based machine using gcc 3.4.1.

Anyway, I downloaded the source for tightvnc-1.2.9, extracted it, and successfully built the utilities without incident (the "xmkmf && make World" steps according to the README). Then the wheels came off when trying to build the server.

The ./configure went off without a hitch, but the make command bombed with a boatload of the same error message:
This was a bit discouraging, because it looks like a fundamental problem with the code, and a glance over WaitFor.c at the lines mentioned referred to a macro definition, and a hard-to-find typedef declaration. I was about to give up when I decided to run the C pre-processor by itself. I was getting lost in all the conditional defines in ${top_src_dir}/Xvnc/include/Xpoll.h (the only spot I saw anything remotely looking like a definition for the data type). So, I kicked off this command:
That spat out a processed file that gave me exactly what I needed: the unobscured data type definition. It just so happened that the data member that WaitFor.c was trying to reference wasn't named fds_bits (matching with the error reported), but in fact named __fds_bits.

So, I went about replacing all the references to fds_bits in WaitFor.c to __fds_bits. Compilation got further, but died again for the same error in other files. All told, I have to modify 4 files:
Compiling went well again, and then bombed at another point. This time, one of the supporting libraries didn't compile: libXau.a. The source code for this library is located in ${top_src_dir}/Xvnc/lib/Xau

The error this time was something like "conflicting types for malloc". In this case, two files had to be modified:
For some reason, the developers decided they needed to re-declare malloc() as returning a char *. I don't mean typecasting, I mean literally trying to declare it as a char * variable, like so:
I have never seen anything like that before with the exception of function pointers, but even then... I don't know if they were trying to use some super-spiffy syntax, but it sure wasn't super-spiffy for my compiler. I commented out all of those declarations in the two mentioned files, and typecast the return result from malloc to a char * when/if malloc was used (some of the functions that contained the funky declaration didn't actually use malloc at all).

After that, compilation finished without a hitch. I kicked off vncviewer, and connected to another machine as expected. Everything else seems to be working normally. So, there you have it. If anybody else needs clarification, let me know, but I have a feeling I'm just "special" and am the only one that had to deal with this.

Sorry, it seems you're not as special as you thought.

I had the same problems on slackware 10 but with a custom kernel and gcc 3.4.3.

Thanks for posting the fix.

you save me lots of debugging:-)
yours.

made a patch: http://runsafe.no/tightvnc-compile.patch

I signed up for this forum years ago, and I can't really remember using it since. Let me say, you guys are awesome.

its a little late in the day for me to start anything, but this thread / patch really has saved my sanity this afternoon. I will try it first thing in the morning.

thanks,

--Yukon / Aaron --

I'm glad the original message was able to help all of you out - and any other folks that may have come across this solution through Google.

Since there are a few of us that ran into the problem, maybe it's time to submit the patch to the tightvnc developers. I went to the tightvnc website and version 1.2.9 is still the current version available for download. If someone has already, then they either aren't interested in making the patch available on their site or they've (hopefully) incorporated it into the next version being worked on. I found a message in the mailing list archive that someone had this same problem... but saw no reply.

I think I have two IDs on this forum, and want to check

ok, this seems like a real n00b question, and I guess in a lot of ways I still am:

I'm trying to use mortenn's patch, and frankly I don't know how . . . maybe someone could give the syntax? I read the man page for "patch," and assuming that's the correct command, I don't know what file to patch . . . when I run the command with:

[root@fed-core3 Xvnc]# patch Xvnc-patch

it seems to crash and I need to use ctrl+c to stop it after 5+ mins. (I copied everything from the page, put it in a file and named it Xvnc-patch). Aslo, I doubt it should make a difference, but I'm running it from:

[akneppar-rh@fed-core3 Xvnc]$ ls -la
total 1124
drwxr-xr-x 7 38577 users 4096 Oct 31 16:32 .
drwxr-xr-x 9 38577 users 4096 Aug 10 13:04 ..
-rw-r--r-- 1 38577 users 2019 Jun 11 2000 bug-report
drwxr-xr-x 6 38577 users 4096 Oct 31 16:23 config
-rwxr-xr-x 1 38577 users 1476 Feb 19 2003 configure
-rw-r--r-- 1 38577 users 14537 Jun 11 2000 DIFFS
drwxr-xr-x 5 root root 4096 Aug 10 13:05 exports
-rw-r--r-- 1 38577 users 4454 Apr 30 2002 Imakefile
drwxr-xr-x 5 38577 users 4096 Oct 31 16:23 include
-rw-r--r-- 1 38577 users 53531 Jun 11 2000 INSTALL.PS
-rw-r--r-- 1 38577 users 22831 Jun 11 2000 INSTALL.TXT
-rw-r--r-- 1 38577 users 3086 Jun 11 2000 LABEL
drwxr-xr-x 7 38577 users 4096 Oct 31 16:23 lib
-rw-r--r-- 1 root root 23292 Oct 31 16:23 Makefile
-rw-r--r-- 1 root root 23292 Oct 31 16:16 Makefile.bak
drwxr-xr-x 3 38577 users 4096 Oct 31 16:23 programs
-rw-r--r-- 1 38577 users 1043 Jan 28 2001 README
-rw-r--r-- 1 38577 users 37447 Jun 11 2000 registry
-rw-r--r-- 1 38577 users 98693 Jun 11 2000 RELNOTES.PS
-rw-r--r-- 1 38577 users 49169 Jun 11 2000 RELNOTES.TXT
-rw-r--r-- 1 root root 723949 Dec 2 2002 vnc-3.3.6-2.i386.rpm
-rw-r--r-- 1 root root 9822 Oct 31 16:32 Xvnc-patch

also Dark Helmet, I came across the same entry in TightVnc's mailing list I think yesterday, and found no response to it either.

The syntax for the patch command can vary some. I just downloaded the source and applied the patch to make sure this works:
From the ls output you listed, you were probably in the right directory.

OUTSTANDING!

dark helmet:
you're great thanks for all the help, once I got the patch loaded make / make install were simple, and the config file was just as easy as the other VNCs I did on oter machines yesterday, thanks again for all your help!

Many thanks for this post and the patch file. Saved me a lot of time.

Thank you, Dark_Helmet and mortenn, for this very useful info.
With your patch, I got a fairly clean compile on Mandrake 10.1.
It got a few "signedness" warnings, and
init.c:947: warning: passing arg 4 of `strftime' makes pointer from integer without a cast
but looked otherwise okay, as far as I could tell as it scrolled past.

Gratefully yours,
-Dave

Hi guys,

I'm trying to install tightvnc on a red hat EV4 server and I get the same error messages as seen in the original posting. Now I had problems with steps prior to Xvnc but I seem to have overcome them through sheer bloody-mindedness. Anyway, my question is do you have any tips on telling if I have the same problem as in the original post? I don't know C at all so reading through fserve.c etc is a bit of a waste of time because I don't really know what I am looking for. I searched the file and found no reference to __fds_bits but then, I don't know if i am meant to.

I know this is stupid, but it is only 10:20 AM and it has already been a long day.

Thanks for your help... and patience... in advance.

K

Edit: Question for Mortenn, I'm assuming the patch just goes through the files and replaces the fds_bits, my question is, does the patch only go through the files mentioned in the original post, or all files in Xvnc?
Only asking because I get the error message in fserve.c too.

Okay, I decided to go for broke and try to run the VNC server anyway, and it seems to work despite not having done anything about the fds_bits errors.

Replies to my earlier post would still be welcome just for personal curiosity, and incase things go wrong in the future.

Thanks guys

Hey duff... It would be hard to say one way or the other whether you have the same problem based on your description. There are tons of other factors involved. Such as:

Have the tightvnc developers made some changes since the code was released? I hope not, because if they did, they ought to assign a new release number.

Does your distro use Xfree or Xorg? After thinking some about the issue, that seems a likely culprit. And specifically, which version of either.

Don't worry, I'm not expecting you to know the answers to those unless you're really gung-ho about research; I "fixed" the problem but never went that deep into it. But here are the answers to your other questions:

The patch will take care of all changes necessary for this particular problem. However, the patch is tunnel-visioned in that it only alters exactly what it's told to. So it will only modify specific files, and it will modify only the portions of those files it's told to.

If you opened up any source files before applying the patch, you won't see any __fds_bits variables. In the original source tarball, the variable name used was fds_bits. The patch changes them to the __fds_bits form.

If you're still unsure about things, I suggest...

Untar the source again, but do it twice (separate locations). Try doing the straight out-of-the-box compile in one, and apply the patch in the other before compiling. Go with whichever one finishes. Warning messages from the compiler can usually be ignored.