Topic: Crash on start up with linux 64 bit filesystem

[itsnotme]

As the title says the application crashes when I start it when the simutrans directory is on an xfs file system

I did an strace which shows the following output (relevant lines only)

Code: [Select]

chdir("/home/andrew/Downloads/simutrans/simutrans/") = 0
open("text/.", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 12
fstat64(12, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents(12, 0x92c219c, 32768)          = -1 EOVERFLOW (Value too large for defined data type)
close(12)                               = 0
open("pak/text/.", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 12
fstat64(12, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents(12, /* 1 entries */, 32768)    = 16
getdents(12, 0x92c219c, 32768)          = -1 EOVERFLOW (Value too large for defined data type)
close(12)                               = 0
write(3, "FATAL ERROR: simmain::main() - U"..., 354) = 354
write(2, "FATAL ERROR: simmain::main() - U"..., 354FATAL ERROR: simmain::main() - Unable to load any language files
*** PLEASE INSTALL PROPER BASE FILES ***

either run ./get_lang_files.sh

or

download a complete simutrans archive and put the text/ folder here.
Aborting program execution ...

For help with this error or to file a bug report please see the Simutrans forum at
http://forum.simutrans.com
) = 354
nanosleep({0, 50000000}, 0xfff45fcc)    = 0
futex(0x8538754, FUTEX_WAKE_PRIVATE, 2147483647) = 1
recvmsg(4, 0xfff45cb4, 0)               = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, 0xfff45cb4, 0)               = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, 0xfff45cb4, 0)               = -1 EAGAIN (Resource temporarily unavailable)
_newselect(5, [4], NULL, NULL, {0, 0})  = 0 (Timeout)
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(15371, 15371, SIGABRT)           = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=15371, si_uid=1000} ---
+++ killed by SIGABRT (core dumped) +++
Aborted (core dumped)


The following line is from the mount command and the disk sdb is a 4TB drive
/dev/sdb2 on /home type xfs (rw,relatime,attr2,inode64,noquota)

When I move the folder to a btrfs filesystem on a 2TB drive simutrans functions correctly

[Ters]

From what I remember, Simutrans does nothing which should depend on the file system, unless the file system implementation is buggy (or behaves very unnaturally, such as not supporting directories). I would rather expect that something went wrong when you copied stuff, but you have provided no information as to how you set up Simutrans to begin with, so I have nothing to go on.

[itsnotme]

it is the getdents not handling a 64bit inode reference

  int getdents(unsigned int fd, struct linux_dirent *dirp,
                    unsigned int count);
       int getdents64(unsigned int fd, struct linux_dirent64 *dirp,
                    unsigned int count);

need to use getdents64!

[Dwachs]

We do not use these functions directly, the code uses opendir, readdir, and related posix functions.

[Ters]

A quick google indicates that XFS is indeed a bit quirky, as I get lots of hits on problems with opendir/readdir on XFS. The problem seems to be that they can't tell the difference between files and directories, as XFS doesn't store that information as easily accessible as the others. However, Simutrans doesn't actually check if the entries are files or directories on POSIX.

The man page for getdents clearly states that getdents is not a function one should use directly, but an internal system call. One should use readdir, which Simutrans does. Although another post I found does point out that opendir/readdir was made when file systems where much simpler, and it's a pain to implement them correctly on modern file systems. No hints of newer alternatives, though. Maybe you have an OS or CRT bug on your hands.

[itsnotme]

the following link gives a good explanation of what is happening and how to code around it.  No distribution issue just XFS default behaviour of not holding info with the inode.  May be time to return to ext4.  At least you all know about this for the future.

http://linux-tips.org/t/readdir-function-on-xfs-filesystem-not-working-properly/115

[Ters]

I saw something similar, but they stated that it only applied to 32-bit processes, not 64-bit processes (even 32-bit processes can possibly be hacked around during compilation), and I have still no idea what you are running.

[prissi]

See the relevant code:

Code: [Select]

lookfor = path + ".";

if (DIR* const dir = opendir(lookfor.c_str())) {
lookfor = (name == "*") ? ext : name + ext;

while (dirent const* const entry = readdir(dir)) {
if(entry->d_name[0]!='.' || (entry->d_name[1]!='.' && entry->d_name[1]!=0)) {
int entry_len = strlen(entry->d_name);
if (strcasecmp(entry->d_name + entry_len - lookfor.size(), lookfor.c_str()) == 0) {
add_entry(path,entry->d_name,prepend_path);
}
}
}
closedir(dir);
}
(void) only_directories;
Nowhere there is any request of file attributes. Only the name. (And the name should be enough for an fopen call ...)

[DrSuperGood]

I believe this is actually a Simutrans error (not a problem with large XFS partitions)...

This error is caused by a lack of Large File Support (LFS). This can occur in 3 situations...
1. Using an out of date glibc. Only 2.1.3 and newer has LFS.
2. Using an out of date Linux kernel. Only 2.4.0 and newer has full LFS.
3. Using the wrong compiler flags/macros. One must explicitly instruct 32bit applications to have LFS. Due to the nature of 64bit applications LFS should be automatic (I cannot confirm this).

To quote the LFS page, any of the following will add LFS...

• Compile your programs with "gcc -D_FILE_OFFSET_BITS=64". This forces all file access calls to use the 64 bit variants. Several types change also, e.g. off_t becomes off64_t. It's therefore important to always use the correct types and to not use e.g. int instead of off_t. For portability with other platforms you should use getconf LFS_CFLAGS which will return -D_FILE_OFFSET_BITS=64 on Linux platforms but might return something else on e.g. Solaris. For linking, you should use the link flags that are reported via getconf LFS_LDFLAGS. On Linux systems, you do not need special link flags.
• Define _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE. With these defines you can use the LFS functions like open64 directly.
• Use the O_LARGEFILE flag with open to operate on large files.

Looking quickly into the Simutrans Makefile I do not see a "-D_FILE_OFFSET_BITS=64" or "getconf LFS_CFLAGS" (recommended) when generating the compiler flag list. This explains why this error is happening as it is not using LFS.

I would strongly recommend adding the flag. With the use of multi-TB hard disks being common in 2016 it seems reasonable that LFS support should be mandatory. This change might break the game for some poorly maintained Linux installs however it is nothing that some updating would not fix.

[itsnotme]

This became an issue for some games on steam (unity) as well so I have a 1TB ext4 SSD drive in for these.  I have just moved simutrans onto there.  BTW as I didnt say I am using opensuse with tumbleweed and have 6x4TB drives (4 as raid) and 2 running as normal.  It is one of the 2 "nrmal" that has my home drive on it with xfs.  Thanks for your efforts. 

Thanks for your efforts.  We are all forewarned for the future.  I will ping a question on the opensuse list and see if anyone has a suggestion and report back.

[Ters]

According to http://www.tcm.phy.cam.ac.uk/sw/inodes64.html, _FILE_OFFSET_BITS is somewhat unsafe to use, but does not go into details why. It might be that it is unsafe to just force it upon a program. One thing is that systems which extract the inode number and put it somewhere, must understand that the field must be bigger now. However, I can think of another issue. If Simutrans is always built with this flags, it will fail on systems (at least when running as 32-bit) which are not built with this flag. As such, it is strictly speaking only an option for self-compilers (and those who compile entire distros for others). (Which I guess is the Unix mentality.)

My 64-bit Linux box gives -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 when I run the 32-bit getconf LFS_CFLAGS. The 64-bit version does not, despite dirent.h being identical. The base type on which off_t is based on is probably 64-bit already, but that makes it unclear what actually defining those things in a 64-bit build will lead to.

[DrSuperGood]

According to http://www.tcm.phy.cam.ac.uk/sw/inodes64.html, _FILE_OFFSET_BITS is somewhat unsafe to use, but does not go into details why.

It can only be unsafe to use if one is manipulating inode fields directly. I doubt Simutrans should be doing this as it should only really care about file/folders and their names and not how/where in a partition the files nodes are located.

If Simutrans is always built with this flags, it will fail on systems (at least when running as 32-bit) which are not built with this flag.

Systems should not be built with the flag. The flag is purely for applications and not the kernel. All kernels since 2.4.0 should support all applications built with -D_FILE_OFFSET_BITS=64 independent of them being 32 or 64 bits. Kernels before 2.4.0 might have problems, but honestly one really should not be using them in 2016 for security and feature reasons.

My 64-bit Linux box gives -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 when I run the 32-bit getconf LFS_CFLAGS. The 64-bit version does not, despite dirent.h being identical. The base type on which off_t is based on is probably 64-bit already, but that makes it unclear what actually defining those things in a 64-bit build will lead to.

Did you test it out? I would imagine it still works.

[Ters]

In the heat, I forgot that the defines also route the calls to different functions (unless they don't, in which case I blame the heat again). None the less, an application that defines those things but is deployed on a system that does not support them, will fail.

And this is not just a question of what the kernel supports, but what glibc supports. I assume 64-bit glibc always supports 64-bit inodes, although we are still just guessing as to whether itsnotme is running a 32-bit or 64-bit Simutrans. With a 32-bit glibc, 64-bit inode support may be optional, although I see no way of deactivating it on Gentoo, and Gentoo is all about being able to tweak such things.

Even if glibc always supports it if new enough and the kernel supports it (can't see anything suggesting that this is configurable, strangely enough), turning this/these flag on in our binary builds means there is possibly a new system requirement. Linux 2.4 is however about the same age (two years older?) as Windows XP, which is our minimum requirement for Windows.

[itsnotme]

I am running a 64 bit opensuse system with the simutrans package from the download link so I expect that is 32 bit.  Running file on the simutrans executable gives
simutrans: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=f28c913ef313f6526fc74290751ea3d8043eca28, stripped

uname -a
Linux host 4.6.4-1-default #1 SMP PREEMPT Mon Jul 11 17:59:12 UTC 2016 (103c936) x86_64 x86_64 x86_64 GNU/Linux

[prissi]

This is getting offtopic, but why should fopen fail on a system using large inodes? I mean this is the task of the stdlib to take care of all that stuff, not the program. The lib could use a translation table, since a 32 bit program cannot open more than one billion file handles anyway in 4 GB ...

Moreover, some virtual servers still run ancient 2.6.x kernels, like the serverlist which also run games. But since a server simutrans is usually self-compiled this should not be an issue.

In the last time Linux gave more headache and becomes more monolithical than Microsoft it seems, the 32/64 comptibility is still an issue on Linux for us.

[Ters]

This is getting offtopic, but why should fopen fail on a system using large inodes? I mean this is the task of the stdlib to take care of all that stuff, not the program.

It's not fopen, it's readdir. readdir returns a dirent structure. In the past, someone got the bright idea to expose the inode number in the dirent structure. On 32-bit platforms, this was exposed as a 32-bit field. But now inodes are no longer 32-bit, because disks have grown since then (probably the 70s, or maybe 80s), and the internal mapping fails when the inode number does not fit in 32-bit. Virtually nobody cares about the inode number, but it is part of the API and must either work correctly or fail. Yes, they messed up, but there is no other solution that doesn't involve breaking backwards compatibility.

In the last time Linux gave more headache and becomes more monolithical than Microsoft it seems, the 32/64 comptibility is still an issue on Linux for us.

Unix-es has always been more monolithical than Microsoft. Their philosophy is to configure and build the entire system from sources, whereas Microsoft has opted for stable ABIs. Even the closed source NVidia driver for Linux needs to compile a few source files in order to work together with however the kernel on that particular system works. And all the executables get lumped together by default in one directory, so that it is impossible to uninstall something again without a package manager, even if it doesn't install system components (which is the only reason for putting something inside c:\windows on Windows).

[DrSuperGood]

I think this is one of those cases where actual practical testing is needed. Try running builds on various Linux installs with "-D_FILE_OFFSET_BITS=64" and such flags. I would be very useful to know that it at least fixes the issue itsnotme is having. We can then start to look at backwards compatibility and other issues it may bring.

What is certain is that more and more people will be using large storage solutions in the future. Building targeting 64bit maybe is a solution but it also degrades game performance and only works for 64bit OS installs. A general 32bit solution to the problem will still be best.

readdir returns a dirent structure

Actually it returns a dirent-like structure. It is a different structure with potentially different memory layout.

[Ters]

I think this is one of those cases where actual practical testing is needed. Try running builds on various Linux installs with "-D_FILE_OFFSET_BITS=64" and such flags. I would be very useful to know that it at least fixes the issue itsnotme is having. We can then start to look at backwards compatibility and other issues it may bring.

Unfortunately, I can't really help there. Not only do I hardly play Simutrans currently (and I'm still playtesting my Unicode changes from last year), I haven't done so on Linux for years. Although I have big disks in my Linux boxes, I don't have the right file system on them. However, all 64-bit file systems should have this problem at least if Simutrans' files happens to end up with an inode numbers above 2³². I also have only 64-bit Simutrans on Linux, my oldest Linux box being pretty much the one where 64-bit Simutrans for Linux was playtested years ago.

I can do some small scale testing with small test programs doing readdir calls (I have already made one just to see if it failed with any XFS file system on 64-bit OS, which it didn't), but that might not be all that gets affected by these changes.

Building targeting 64bit maybe is a solution but it also degrades game performance and only works for 64bit OS installs.

There might actually be more 64-bit OS-es without 32-bit support than 32-bit OS-es without large file support amongst our users and potential users. It seems 32-bit compatibility isn't on by default on many (most?) distros. Because why should it, when the distro comes with 64-bit builds of everything included? Moving binaries between systems is not the way of the Linux world. You are supposed to get the sources and ./configure && make && make install, and that should give 64-bit users a 64-bit executable.

Actually it returns a dirent-like structure. It is a different structure with potentially different memory layout.

Maybe you confuse the Linux syscall with the POSIX function? The POSIX function says it returns a dirent (well, a pointer to one). It is the POSIX function Simutrans calls. I guess the POSIX readdir used to call the readdir syscall, but now apparently uses the getdent syscall instead.

[DrSuperGood]

Maybe you confuse the Linux syscall with the POSIX function? The POSIX function says it returns a dirent (well, a pointer to one). It is the POSIX function Simutrans calls. I guess the POSIX readdir used to call the readdir syscall, but now apparently uses the getdent syscall instead.

If you read the note...

Only the fields d_name and d_ino are specified in POSIX.1-2001. The remaining fields are available on many, but not all systems. Under glibc, programs can check for the availability of the fields not defined in POSIX.1 by testing whether the macros _DIRENT_HAVE_D_NAMLEN, _DIRENT_HAVE_D_RECLEN, _DIRENT_HAVE_D_OFF, or _DIRENT_HAVE_D_TYPE are defined.

Other than Linux, the d_type field is available mainly only on BSD systems. This field makes it possible to avoid the expense of calling lstat(2) if further actions depend on the type of the file. If the _BSD_SOURCE feature test macro is defined, then glibc defines the following macro constants for the value returned in d_type:

In the implementation there are also comments further supporting this. Although one can in theory return a getdent formatted structure, it is not required to. This is because getdent is a Linux kernel call while readdir is an API, the structures used may be the same but are technically different.

[Ters]

Although one can in theory return a getdent formatted structure, it is not required to. This is because getdent is a Linux kernel call while readdir is an API, the structures used may be the same but are technically different.

Now you write getdent-structure. That's something else.

[DrSuperGood]

Now you write getdent-structure. That's something else.

These Linux APIs are too confusing...

If compiler flags (recommend approach?) does not work then what about the hard-linked approach? With the _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE definitions the appropriate function versions should be able to be linked directly. I am unsure if this is just with glibc or not so it might affect portability.

[Ters]

If compiler flags (recommend approach?) does not work then what about the hard-linked approach? With the _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE definitions the appropriate function versions should be able to be linked directly. I am unsure if this is just with glibc or not so it might affect portability.

The 64-bit version of readdir seems to be undocumented (except on BlackBerry). But the possible compatibility problem is at runtime, not compile time. Whether we use compiler flags or simply hardcode calls to readdir64, we end up with an executable that references readdir64. That won't work on a system that doesn't have large file support. It's the compiler flags or nothing.

[prissi]

I may also not compile on the nightly compile farm, which is a 32 bit system ...

[DrSuperGood]

I may also not compile on the nightly compile farm, which is a 32 bit system ...

It will compile correctly as long as the server has LFS. In fact I doubt the OS needs to even support LFS in order to compile a build supporting LFS. From what I read pretty much all Linux versions (both 32bit and 64bit) support LFS since 2005. One can argue if one really should still be using a Linux kernel older than 2005, especially seeing how upgrading is usually free and recommended from a feature/security point of view.

Both 32bit and 64bit versions of Linux have LFS as the limit was purely system and C API based and not architectural. Turning on LFS for 64bit builds does nothing (they always have LFS). Any performance impact from using LFS should be completely trivial. With LFS support enabled both partitions and file size of a XFS partition are limited to 8 EiB (8*1024^6 bytes) which is beyond anything reasonable for consumer use currently.

I guess the big question is how many Linux players use very old Linux versions? If >95% use kernel versions newer than 2005 then there should be no problem at all with forcing LFS.

[Ters]

In fact I doubt the OS needs to even support LFS in order to compile a build supporting LFS.

Features on Linux are generally configured at compile time. I consider it likely that glibc will not compile any readdir64 if the kernel does not support it. If the linker needs the symbol in the import library, it will likely fail then. But given the age of LFS support, I strongly doubt the build server is missing that feature. Only way to know is to try it out.

Any performance impact from using LFS should be completely trivial.

It might actually be a performance increase. At least on 64-bit systems, and possibly LFS 32-bit systems as well, there is a compatibility layer that actually does some checks. But yes, trivial, and in a by no means performance critical part of Simutrans.

I guess the big question is how many Linux players use very old Linux versions? If >95% use kernel versions newer than 2005 then there should be no problem at all with forcing LFS.

And as a last option, they still have the option of getting the source code, disabling LFS-support and building Simutrans themselves. Although that argument works both ways.

[itsnotme]

Just to confirm that I have compiled trunk on 64bit and it all works fine.  However, haven't got the cross compile working yet  to test the LFS as I get lots of these errors during compile

besch/bild_besch.cc: In member function ‘bild_besch_t* bild_besch_t::copy_fliphorizontal() const’:
besch/bild_besch.cc:416:74: error: exception cleanup for this placement new selects non-placement operator delete [-fpermissive]
  bild_besch_t* target_besch = new(pic.len * sizeof(PIXVAL)) bild_besch_t();

I will build a 32 bit VM compile it and test for you

[Ters]

besch/bild_besch.cc: In member function ‘bild_besch_t* bild_besch_t::copy_fliphorizontal() const’:
besch/bild_besch.cc:416:74: error: exception cleanup for this placement new selects non-placement operator delete [-fpermissive]
  bild_besch_t* target_besch = new(pic.len * sizeof(PIXVAL)) bild_besch_t();

Doesn't look cross-compilation or 32/64 related to me. Probably something to do with how picky/conforming the compiler you use is. I don't get this with gcc 4.9.3 on the newest code.

[itsnotme]

Yeah I have gcc 6 and it throws this only when cross compiling and then if I add -fpermissive it then fails at the g++ compile so need to look at that (lots of undefined refs).  Just think it is easier to make a 32 bit VM and be lazy than work out all the libs for cpp  32bit

OK further investigation is the linking fails and I am not going through the makefile and ensure all the linking uses 32bit.  So VM it has to be.

[Ters]

I didn't have much trouble setting up a cross-compiler on Linux, although it has been over a year since I did it. All I had to do was specify the correct CC, CXX and LD in the config file. This was without/before autoconf, though. I doubt that sets things up properly. Naturally, the cross compile environment must of course exist and contain all necessary libraries.

[Dwachs]

besch/bild_besch.cc: In member function ‘bild_besch_t* bild_besch_t::copy_fliphorizontal() const’:
besch/bild_besch.cc:416:74: error: exception cleanup for this placement new selects non-placement operator delete [-fpermissive]
  bild_besch_t* target_besch = new(pic.len * sizeof(PIXVAL)) bild_besch_t();

Seems like bild_besch_t is (always?) allocated by placement-new, without corresponding cleanup.

[Ters]

Seems like bild_besch_t is (always?) allocated by placement-new, without corresponding cleanup.

I think it is complaining about that obj_besch_t declares it's own special new operator, taking an extra parameter, but no corresponding delete operator, to be used to free the memory allocated if the constructor throws an exception. From what I can find, this is legal, but means memory won't be deallocated upon constructor failure (a very hypothetical situation for besch classes if I remember right, but that may not be apparent for the compiler). However, the compiler's complaint seems to indicate that the compiler is generating code that deallocates the memory if an exception is thrown.

[itsnotme]

So good news

I have compiled a 32bit version with large file support (switches detailed above) and it runs correctly (limited testing) on the large filesystem (same files/inodes that had issues initially).  So that means it works with either 64bit compile or 32bit with large filesystem support.    

Compiled on a 32bit VM running opensuse tumbleweed

Code: [Select]

#On 32bit VM
andrew@linux-m7sp:~/Downloads/simutrans/code/trunk> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-suse-linux/6/lto-wrapper
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada,go --enable-checking=release --with-gxx-include-dir=/usr/include/c++/6 --enable-ssp --disable-libssp --disable-libvtv --disable-libcc1 --enable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-6 --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=i586-suse-linux --host=i586-suse-linux
Thread model: posix
gcc version 6.1.1 20160707 [gcc-6-branch revision 238088] (SUSE Linux)

#On the host 64bit system
andrew@host:~/Downloads/simutrans/simutrans> file /home/andrew/Downloads/simutrans/simutrans/simutrans-largefs-32bit
/home/andrew/Downloads/simutrans/simutrans/simutrans-largefs-32bit: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.0.0, BuildID[sha1]=b44a32da47fc14619e1401725782729e7b0c03ff, not stripped




Note that I still had to add the -fpermissive flag to the compiler flags

Grateful for the efforts you have all put in.  I now know why I can't run it from steam and get no errors.  BTW I was a long term player back in the old days before prissi took over the dev and was around for some time until World of Warcraft took over my life (given it up now so starting to play lots of things). 

[TurfIt]

initially).  So that means it works with either 64bit compile or 32bit with large filesystem support.    

How about compiled 32 bit on your system without the large file flags? i.e. Is it possibly just a problem with the OTTD compile farm provided executable. Also, does OTTD work? Especially their generic 32 bit linux binaries.

gcc version 6.1.1 20160707 [gcc-6-branch revision 238088] (SUSE Linux)

Note that I still had to add the -fpermissive flag to the compiler flags

I believe GGC6 now uses C++14 instead of 98 by default. One of the standard updates in there mangled the placement operator functionality, so try setting it back to using 98. -fpermissive should be a last resort as it's usually code errors one is bypassing by it.

[itsnotme]

Good catch.  Adding the -ansi flag to the CFLAGS and CCFLAGS and removing the -fpermissive removed all the errors/warnings. 

To answer your second question I compiled and tried a 32bit version without the large filesystem support and this version of the application cannot detect the pak file directories.

 

[prissi]

Could you give the flags and defines you used?