Compiling under Linux

[Mincho Georgiev]

It took me quite a while to familiarize myself with the environment but thanks to your support I made some major progress.

I am now at a point where I am getting my first Intel C++ compiler error messages : "could not open source file "Windows.h"" ... what a surprise.
So my next step will be to find an alternative Linux solution for
- pipe/console management and
- time management

but I am sure I will find some references to this in one of the available linux engines. Thanks again for the introduction to this new Operating system!

If you are able to see that message, I guess everything is ok now. You can look at Pawny's code, the time and piping works ok under linux.

[Michel]

You keep using it "properly", and I will keep like it as I do.

Of course you can use it however you like. But I think it is wrong to give others bad advice on how to use linux. There are extremely good reasons for the separation between root and user accounts.

Practically all security problems on Windows are due to the fact that until very recently every user was using an Administrator account for day to day use (as Windows was effectively unusable without it). Even now, when this is no longer the case there are still lots of problems since Microsoft somehow has to emulate the old behaviour with all kinds of dangerous implicit privilege escalation hacks.

[jshriver]

IF you need a 32bit compile I would be more than willing to port/clean it up for linux distribution. Even willing to sign a nondisclosure agreement pennding I can have a copy

[Chan Rasjid]

You keep using it "properly", and I will keep like it as I do.

Of course you can use it however you like. But I think it is wrong to give others bad advice on how to use linux. There are extremely good reasons for the separation between root and user accounts.

Practically all security problems on Windows are due to the fact that until very recently every user was using an Administrator account for day to day use (as Windows was effectively unusable without it). Even now, when this is no longer the case there are still lots of problems since Microsoft somehow has to emulate the old behaviour with all kinds of dangerous implicit privilege escalation hacks.

I think there must be a reason that root is not to be used unless strictly necessary.

But installation of packages (intel compilers, etc..) generally requires root user. But for me using Debian, it is synaptic manager that does all the installation and is is ok.

Rasjid

[Edmund]

another major step forward. I was able to compile correctly and run the engine. The next problem is a thrown assert everytime in move_unmake. That happens during a sanity check that current hash == hash before movemake.

Maybe that has to do with a little workaround I quickly implemented concerning _byteswap_uint64. I need this function for my zobrist key but this was not supported when I tried my compile under Linux. So I rewrote the function using shifts. It worked perfectly on Windows, but whether that might be the problem on Linux I am not sure. Anyway is there a way to use this byteswap intrinsic under Linux?

[Mincho Georgiev]

another major step forward. I was able to compile correctly and run the engine. The next problem is a thrown assert everytime in move_unmake. That happens during a sanity check that current hash == hash before movemake.

Maybe that has to do with a little workaround I quickly implemented concerning _byteswap_uint64. I need this function for my zobrist key but this was not supported when I tried my compile under Linux. So I rewrote the function using shifts. It worked perfectly on Windows, but whether that might be the problem on Linux I am not sure. Anyway is there a way to use this byteswap intrinsic under Linux?

Even if it's possible, could differ from your own, so in order to make sure that intrinsic works ok, you could test them trough the intel debugger, which is awesome. in the compiler installation directory, you should find the "idb" script. It's enough to compile you executable with -g flag only (/Zi is not needed like under windows) and then execute the script like:

Code: Select all

./idb myexecutable

[Edmund]

I now got the last mentioned problem fixed. It was about asserts under Linux also getting executed with the debug flag set.

The next issue is a sudden "Segmentation Fault" message and the engine quits. I never had this issue under Windows where I also tested with bounds-checking. Are there any easy ways to debug segfaults?

[Mincho Georgiev]

I now got the last mentioned problem fixed. It was about asserts under Linux also getting executed with the debug flag set.

The next issue is a sudden "Segmentation Fault" message and the engine quits. I never had this issue under Windows where I also tested with bounds-checking. Are there any easy ways to debug segfaults?

It's hard to answer that question. Sengmentation fault could be caused by a lot of things, used unitialized ptr, buffer overflow, storage violation. You know your code best, so should be able to find it easy if you give Intel debugger a try.

[Michel]

The next issue is a sudden "Segmentation Fault" message and the engine quits. I never had this issue under Windows where I also tested with bounds-checking. Are there any easy ways to debug segfaults?

Segfaults are scary but they are usually easily found with a debugger.

Using gdb you would do

Code: Select all

gdb <executable>

&#40;gdb&#41; run

<< program running >>
<< segfault  >>

&#40;gdb&#41; bt

This gives you a backtrace which tells you were the segfault is.

EDIT: for this to work you should of course compile your program with
debugging symbols (-g with gcc).

[Edmund]

Thank you, all the bugs solved now! This time the problem was about printf requiring %llu and not %I64u like in windows.
So many details one has to be aware of.

I was now able to get the engine compiled and it ran flawlessly in the terminal. However I didnt get it to run under scid. Is there anyone who would volunteer to test this Linux compile of mine?