GCC 2.95 last working compiler w/o Varargs issues

[Holyavenger]

It took me a little research to find out why various drivers (older) were failing to compile.
Basically, after 2.9k/ their was a much more stricter GCC. Futhermore, if you are using x64, like
most of us, most likely older drivers need to be compiled in 32bit mode.

FAILED: Experiments x64 Win 7: Amylaar,FluffOS/MUDOS , MGWin,Cygwin all with 4.5gcc.

Only LDmud compiled

Success: SuSe 11.3 x64 FluffOS/LDMUD w/gcc 4.5
Redhat 6.1 w 2.95 gcc ALL compiled.

Relevant citations:
http://kerneltrap.org/node/5974

[quixadhal]

FluffOS 2.21 compiles fine on my Debian x64 VM.  I would suggest this is yet another reason to stay away from Cygwhine.

Code: [Select]

make[1]: Leaving directory `/home/quixadhal/ds3.1a11/fluffos-2.21-ds01'
quixadhal@virt4:~/ds3.1a11/fluffos-2.21-ds01$ ls -al driver
-rwxr-xr-x 1 quixadhal quixadhal 712132 Jan  8 18:40 driver
quixadhal@virt4:~/ds3.1a11/fluffos-2.21-ds01$ file driver
driver: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

A few warnings, but nothing show-stopping.

Code: [Select]

quixadhal@virt4:~/ds3.1a11/fluffos-2.21-ds01$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)


[Holyavenger]

I modified the path statements ->my computer->advanced properties->environmental and made sure c:\cygwin\bin was the first listed.

FluffOS compiled  :2.17, 2.21ds, 2.27
            failed      : 2.29ds failed -> dropped with time stamp error.

All compile under x64 SUSE fine.

The reason why I keep toying with win 7 compiled software is pure experimentaion. Learning the snags in the process is a learning experience. Basically, shaking off rust on linux skills. Warcraft pvp has distracted me for year!

Andrew

[quixadhal]

Oh, also... from your subject line:

Code: [Select]

quixadhal@brezhnev:~$ less /usr/lib/gcc/i486-linux-gnu/4.4/include/varargs.h
#ifndef _VARARGS_H
#define _VARARGS_H

#error "GCC no longer implements <varargs.h>."
#error "Revise your code to use <stdarg.h>."

#endif

I had to do that a couple years ago for my old DikuMUD.

[wodan]

FluffOS and windows currently disagree on the size of a long var on 64 bit systems, so you'll have to go 32 bit on windows for now.
Cratylus has had success compiling it with mingw, I haven't heard of a succesful build on cygwin in years (it builds, but save files don't work).

[Holyavenger]

FluffOS and windows currently disagree on the size of a long var on 64 bit systems, so you'll have to go 32 bit on windows for now.
Cratylus has had success compiling it with mingw, I haven't heard of a succesful build on cygwin in years (it builds, but save files don't work).

Woden, I'll double check on the file saves. I may have a couple left over cygwin x64 driver.exe's that may be useful for the experiment  I've since reverted my cygwin to gcc 2.95 32bit, which hasnt failed in any so far.

[quixadhal]

Not to be a monkey and fling things, but.... is there any real value in ANYONE continuing to mess with Cygwin?  Wouldn't the community be far better served by migrating FluffOS (and other drivers that claim to function under windows) to native Windows support?

Anyone can download a free version of Visual Studio Express these days, so the old excuse of "I can't afford it" doesn't fly.  Clearly, an app running natively is going to be much easier to debug AND can be run as a service, thus eliminating the tedium of emulating bash scripts to keep things going.

I think Crat had the right idea in trying to update old mudlibs to run under the current FluffOS driver, and I'd go the extra step and say if you want it to work under Windows, then make it work under Windows, not some hackish emulation of bits of unix.

[Raudhrskal]

It does run under native windows. Compiled with Mingw32. What's your point?

[quixadhal]

That's not native.  That's using a compatibility layer.  Does it compile with Visual Studio, which is the native development environment that any serious windows application programmer will be likely to use?

If not, why not?  Real lack of time to put into it, or Unix snobbery?  I'm not dissing you guys here, I'm trying to suggest that people who want to run a MUD under Windows (whatever the reason), would probably be a lot more comfortable using the tools they're used to using already, and working in an environment they're familiar with.

Being a gcc/vi guy myself, I know I don't enjoy being told to suck it up and go use Eclipse to work on java code.  In fact, most of the time it means I don't bother.  Mucking through class hierarchies in vim really isn't all that much fun.  Now, imagine you're used to Visual Studio and are told you have to use this crufty unix compiler and notepad?  Nonsense.

[Raudhrskal]

Quix, it RUNS on native Windows runtime libraries... the same ones MSVC apps use, actually. Cygwin is compatibility layer. MinGW is native.
And expecting a Standard POSIX C program, that works on a ton of platforms out of the box, to MSVC compiler, that deprecated half of the Standard C functions and renamed other half, would be useless waste of time.
Also, many "serious windows applications programmers" use Eclipse.
Also, you *can* use MSVC as your editor, you just need to compile outside of it, which's one easy command. And if you have a commercial version, you can actually plug in gcc & gdb into the IDE via an extension, I think.

[quixadhal]

We're talking two totally different kinds of "native" here.

To you, native apparently means runs without extra DLL's, and that's it.  To me, native means using the accepted default API's *and* the accepted standard development tools for the platform in question.  Yes, some people use Eclipse in Windows.  Most of them are current or former java developers.  Yes, you can kludge gcc into Visual Studio, or you can kludge the visual studio editor into working with other IDE's.  Neither of these is normal.

One of the jobs I had back in 2000 was doing Visual Basic programming (with SQL server).  We had an older codebase written in VB3, and a newer one developed in VB5.  Technically, you could have loaded both sets of code into either environment, as long as you made sure the compilers/libraries/etc were pointing in the right directions.  Nobody ever did that.  Ever.  We installed both copies and worked in whichever one we needed to use.

As a unix guy, I'm very comfortable using gdb/grep/diff and other command line tools to debug code problems.  A Windows person will NOT feel the same way, no matter if the tools exist and are useable.  To them, the VS debugger is their comfort zone, and that's the point I'm trying to make.

So, I'm not making any sort of argument about what you CAN do.  I'm saying that the normal windows development environment is Visual Studio, and if FluffOS wants to claim windows support, it really should work in such an environment.  If one also wanted to support Eclipse, it would probably make the OS X people happy, and perhaps the Solaris people as well... but that's another story.

As to it being a useless waste of time... I guess that depends.  If *YOU* were a Windows programmer, or if *YOU* wanted to ensure that the audience of Windows programmers would be able to work with the driver and thus contribute code and bug fixes to it, you might not consider it to be a waste of time.

Looking at it from the other side of the fence... when I use a windows app and it has an obvious bug that I know how to fix, I am sad to say that I usually don't do so BECAUSE I'm not familiar with the current Visual Studio environment.  If they had provided me with a makefile and enough #ifdef's in the source to let it compile under linux, I'd fix the issue and mail them a diff.  But instead, I mail them a bug report.  It's not because the bug is hard, the development environment is hard (for me).

That same reasoning applies in the other direction.  How many bugs might have been fixed over the years if even a few of the people who drag the thing into running under Windows could use their native debugger to track and fix issues?  I have no idea.  Enough to make it not a waste of time?  Maybe.

[cratylus]

I think both of you are pretty smart and I groove with arguments both of you make.

But it seems to me there is some mootness here.

Sure, on occasion the driver needs to be futzed with, but in general, an lpmud (note the name of the site)
doesn't really need that much fiddling with within an IDE.

Sure, there are infelicities in FluffOS on Windows, granted. But I'd expect that someone in a position to
so srs fluffcoding would be willing to rough it a little, outside their comfort zone. cf Kalinash

I think I support the idea of "real portability", but considering that fluff is supposed to be a VM to handle
the REAL development , which is in LPC, it is possible to take driver portability a step or two too far.

-Crat