How can I forward the X display to my machine? And, I've tried wineconsole and just wine, both do the same. Also, I am doing everything through SSH to my remote box.

I am a novice when it comes to Linux so I just need a little further explaining.

Quote from Nathan D. :

How can I forward the X display to my machine?

Well, you could google about it for more information about setting $DISPLAY etc... But a quick way to enable it is to just initiate an ssh with ' -X ' switch and it should work immediately (the ssh client will try to do all the stuff automagically). ;-)

This is only to determine what errors LFS emits. After you're done resolving any errors with the configuration file, then there should be no need for all this X forwarding.

(Edit: I am assuming that the client machine you are on also runs Linux or similar. If you are on windows, you would obviously need a Windows X Server to see the display.)

Yes, I am on a Windows client.

I downloaded Xming X Server and am using Putty as my SSH client. Not sure what to do from here though.

I noticed that when using "wine LFS.exe /cfg=server.cfg" to run the LFS server, I get a different error:
ALSA lib seq_hw.c:457snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory

i run my servers in NX... it satisfies the need for an X server, and allows me to disconnect from the "screen" if and when i need to.

nathan, the error you're getting is either because your alsa is messed up, or because wine is looking for a midi that might or might not be there... if you have a choice of compiling wine, you can remove midi support.

Quote from bunder9999 :

i run my servers in NX... it satisfies the need for an X server, and allows me to disconnect from the "screen" if and when i need to.

nathan, the error you're getting is either because your alsa is messed up, or because wine is looking for a midi that might or might not be there... if you have a choice of compiling wine, you can remove midi support.

Could you provide some assistance with this? How can we confirm that wine is looking for a midi, and once confirmed, how can I recompile wine?

By the way, my OS is CentOS 5.2 64bit if that helps.

Bump. I really want to get a server going but I don't know much about Wine. Please someone help.

http://winehq.org

you're welcome.

For future reference, if you can't find a package of wine that works without X11 for your distribution, you can re-compile wine with --without-opengl and --without-x options passed to ./configure

More detailed:
download tar.gz or tar.bz2 file from http://winehq.org

Unpack it with:
tar xvf wine-*.tar.gz (replace the file with the file you've downloaded)
cd into the dir that you have unpacked that tarball and run configure with above options:
./configure --without-opengl --without-x
When configure finishes run make with, yes simple:
make
When build finishes(go grab a beer or two):
run:
make install AS ROOT!!!!

Why not apt-get/aptitude install wine ?
Then wine LFS.exe /cfg=setup.cfg and done.

Quote from misiek08 :

Why not apt-get/aptitude install wine ?
Then wine LFS.exe /cfg=setup.cfg and done.

Not everyone is using Ubuntu/Debian(thank god) and I don't even know if it will install under Ubuntu that way. X11 might come up as dep. packet. And if you don't want X11 on your server(which you probably don't if you have everything in place "up there") then your best shot is to either find a precompiled package of wine that has been compiled with above options or you compile if your self. Which I personally prefer.

"dpkg --force-depends wine.deb" will ignore dependencies, so you don't have to install X11, PulseAudio and some other stuff you don't need on a server to run LFS Dedi.

Compiling and installing apps directly from source is usually a bad practice if you run a distro with extensive package management (pretty much every distro except LFS). Possible file conflicts and inability to actually uninstall such software without the risk of breaking something is usually not worth it. Most distros offer tools to build a proper package from source anyway, so I don't see any reason why would anyone want to use the "configure, make, make install" way.

Compiling is bad?
If you compile software on your own machine it is better than download a compiled package. File conflicts? I've never had those and I've been compiling software from source since like, forever.

And again, dpkg. Another distro specific software. make is cross-distro, so it will work anywhere, as long as you have the right libs and compilers installed.

I do agree that "make install" files are harder to hunt down, but like you said, you can have the source compiled and packaged in a distro specific package and install that. I just didn't want to include it in the above "guide", because it would again be distro specific.
But if you want it, you can use src2pkg on slackware. Maybe even on some others, but I cba to try out other distros.

Quote from xfirestorm :

Compiling is bad?

Of course not, it's the subsequent installation outside the packaging system that can set you hell bound. It doesn't have to if you're careful and set a different install prefix than / or /usr and use your brain while doing it

Don't make me wrong, I agree with you that "configure, make, make install" works anywhere, anytime on anything, I just thought I'd mention some of the risks this approach has.

If the source software package was made by a moron or the software it self was written by a moron, who will use a common name for his own libs i.e., it would be risky yes. Because if he named his one of his libs "libglib.so", you'd have a problem if you installed this and overwrite the original lib.
But AFAIK, wine is not developed by morons and their lib names are quite different from other software, so there is no danger in manually compiling and installing wine.

If you are still afraid you'll overwrite something or that you'll have to spend much time hunting down files to delete should you decide to remove the software, you could pass "--preffix=/opt/mysoftware" to install it in that dir. You would then need to alter your $PATH or pass "--bindir=/usr/bin --sbindir=/usr/sbin" to have the binaries installed in a place that is already included in $PATH.

Quote from xfirestorm :

You would then need to alter your $PATH or pass "--bindir=/usr/bin --sbindir=/usr/sbin" to have the binaries installed in a place that is already included in $PATH.

Linux has this wonderful thing called 'symlinks'.

Orly nao? Haven't noticed those in the past 10 years working with Linux.

Or yes, you could make symlinks into /usr/(s)bin

Quote from xfirestorm :

When build finishes(go grab a beer or two):
run:
make install AS ROOT!!!!

You can run Wine directly from the source tree, no need to install, and no need for root access.

Well I've ran into a problem now.
LFS server has been running fine, has shown up on server list and people could connect to it.
Now I've recompiled the kernel to the newest stable, 2.6.37.2, and the server doesn't show up on lfsworld.net server list anymore. Why is that? Inspecting the connection list it is connected to LFS:
tcp 0 0 my-IP:29999 lfs-IP:61506 ESTABLISHED 23372/wineserver
tcp 0 0 my-IP:47387 lfs-IP:29339 ESTABLISHED 23372/wineserver

So firewall is not blocking. The darn thing just doesn't show up there. I'm guessing it doesn't show up in the game either, and no I can not test it out right now. But if anyone would be so kind, server name is "GT3 Racing", without quotes.

It also shows that airio does connect to the server, so have no clue what's going on.

It might not have directly to do with recomplining the kernel,
but my experience is, that stopping/starting a host running via wine makes it not showing up in server list.
When I put a delay between stopping and starting however non such problem occures.

One other thing, if you like to have full control of your binaries (=compile them from source) and squeeze the last bit out of your hardware try gentoo distribution.

If it's any help, I'm able to connect to your server by typing its name directly in the Join Specific Server screen. However, I can't see on lfsworld nor in the game.

Quote from yankman :

One other thing, if you like to have full control of your binaries (=compile them from source) and squeeze the last bit out of your hardware try gentoo distribution.

<-- Slackware maniac. Thanks for the tip tho.

I know, stopping and starting right after makes it act...strange...mostly, the insim port doesn't get bound, but that's not the problem here, as it is listening on both ports.
I know it might not be kernel-recompile-related, but that is the last thing that I have done on the system, so I'm kinda, sorta out of ideas.
And inspecting the whole thing on my side, it seems to be working good, but I have no clue why is it not showing up there. I have even enabled logging everything from my firewall to see if anything LFS related gets blocked, but all passes through just fine.

Thanks MadCatX for trying it out.

I wasn't talking about binding port tho.

It is like I said, if I stopped a host (via kill) and then started it with no delay,
it did not appear on lfsworld.

But shame on me I just tested it 2 times and now it appears even with no delay.

Little OT: If you really going in gentoo, I could give you same valueable tipps.

I'm not going on Gentoo. I use Slackware for ages. Gentoo doesn't offer anything special to me that it would be worth for me to change the distro.
I compile everything from code anyway, by hand or by using slackbuilds.

I know what you meant, and I've also tried shutting down the server(LFS ofc, not the whole machine) and leaving it like that for 30 minutes and starting again, with no effect.

You could try starting the server on Windows to see if it appears on the master server then. If it does, you can launch it on your Linux server again. If anything, it might help you diagnose where the problem is. Also downgrading to 2.6.37.1 might be worth a try just to eliminate an improbable possibility of a glitch in the kernel.

I'm such an idiot.
I had /usemaster=hidden in the cfg