I've used the Cygwin version of gcc enough to know that the order of items you place in the command line matters, and also that there is a long list of options for telling it to do only some of the compilation steps.
Could it be forcing the inclusion of more than one header file to the first line of the primary source file, and not in the order you want?
That's indeed likely. A great trouble here is that there is considerable depth in the toolchains that are downloaded with the packages, so I'm reluctant to dive in too deep there. I might solve my problem and unknowingly introduce another worse one.
As far as I can tell : the x86-mingw32-build.sh.conf ( and thus the patch for that ) can set eg.
option CFLAGS_FOR_RUNTIME -D__USE_W32_SOCKETS
and such things appear in the output of the build script, echoing the gcc command invocation. But that's at about line 4200+ so heaven knows what might precede that and yet be relevant.
Thanks for your thoughts :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
OK. I'm dying to release something .... it's time to find out if it flies or I go down in flames. Where's my Nomex underwear ?! :-) :-)
So here is the linux version of work so far - sorry Windows and Mac users you'll have to wait for build script issues to settle. :-(
It's an ~ 11MB zip ( executable and images ) that I recommend downloading to a suitably empty directory, then unzip it and run : [pre] graphics_app=einstein_SOLARSYSTEM_V0_1_graphics_i686-pc-linux-gnu[/pre]
I've shifted the initial craft position to bring the Earth into your immediate first view. Remember if you can't see the HUD it's probably because the window/screen dimensions are too small.
By all means report any problems/concerns whatsoever. Two files are created ( in the same directory as the executable ) that may give helpful error output :
[pre] stderrgfx.txt
solarsystem_stderr.txt[/pre]
When invoked from a terminal screen/window then other information is also emitted there.
I expect two main categories of issues:
- huge programming boners that I've made. Missing the bleeding obvious etc ...
- native graphics driver OpenGL support ....
Known minor issues :
- textures on polar caps of Earth and Sun don't quite cover ( small wedge missing )
- constellations coming alphabetically after Taurus yet to be incorporated
- glitches on multi-monitor systems
- being a debug build it has alot of code for that purpose, so it might be 'laggy' at times. Especially on resize as many of the underlying objects have to be destroyed and then reconstructed.
Now pretty much all visual or user-interface aspects are easily configurable during builds ie. colors, sizes, positions, speeds, keycodes, or whatever. Thus I would also be most grateful for any 'style' based feedback.
Cheers, Mike.
( edit ) Oh, and to satisfy GLPL2 the source code is referenced ( lower screen ) at GitHub, SolarSystem branch, tag name "V0.1" - try here
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Yep, don't use x86-mingw32-build.sh :-) I stopped using it when I needed gcc 4 support and since then I use Debian's stock MinGW - works like a charm, e.g. for our Windows BRP science applications (including CUDA and OpenCL!). Shame on me though that I haven't yet ported this change back to the graphics framework! You should have told me earlier ;-)
I wonder, should I do this now? It would introduce an additional dependency on an existing MinGW installation on the cross-compile Linux host though.
Oliver, I would appreciate it if you could do the mingw change soon, or at least tell us a workaround on how to modify the build script for a system that has the mingw-gcc installed.
[Edit#2]
I can't get the BOINC compile (on Mac) to recognize the libjpeg of MAcPorts. Do your Makefiles honor CPPFLAGS and LDFlags from the environment, or just overwrite these?
[/Edit#2]
Ok, and finally (that one's probably for Mike to fix):
[pre]
In file included from /Users/bema/Einstein-At-Home-Screensaver/src/framework/../solarsystem/SolarSystem.h:41,
from /Users/bema/Einstein-At-Home-Screensaver/src/framework/../solarsystem/SolarSystemS5R3.h:24,
from /Users/bema/Einstein-At-Home-Screensaver/src/framework/GraphicsEngineFactory.h:25,
from /Users/bema/Einstein-At-Home-Screensaver/src/framework/GraphicsEngineFactory.cpp:21:
/Users/bema/Einstein-At-Home-Screensaver/src/framework/../solarsystem/Simulation.h:41:31: error: HUDTextLineScroll.h: No such file or directory
[/pre]
Below is a short diff to the build script that made it work for me this far on the MAc:
Oliver, I would appreciate it if you could do the mingw change soon, or at least tell us a workaround on how to modify the build script for a system that has the mingw-gcc installed.
Most of the times it's a temporary issue with the mirrors, or they changed/removed the version entirely (needs to be updated in that case).
Quote:
I can't get the BOINC compile (on Mac) to recognize the libjpeg of MAcPorts. Do your Makefiles honor CPPFLAGS and LDFlags from the environment, or just overwrite these?
I can't get the BOINC compile (on Mac) to recognize the libjpeg of MAcPorts. Do your Makefiles honor CPPFLAGS and LDFlags from the environment, or just overwrite these?
I "discovered" my old mingw_gcc44 branch that already contains the necessary commits to use a standard MinGW installation - in my case the one provided by Debian. I don't know how well it translates to other Linux distributions. Give it a try.
Since your branch is based on our master you can simply merge it into your branch -- or just cherry-pick the two latest commits from master. Regarding the mingw_gcc44 branch I recommend you check it out locally and rebase it using your branch. This way you should get your branch with the required MinGW patches applied on top of it :-)
Please note that libxml2 might throw an error WRT libiconv when cross-compiling for Windows. This is a known issue I fixed on my build machine. I intend to fix this permanently in the build script itself shortly (this week?). In case you hit this one, bear with me for a few more days.
OK, thanks for the input guys. I should have spoken up sooner. ;-)
- HUDTextLineScroll class has been pushed to my GitHUb. Sorry 'bout that ....
- as regards
Quote:
I'm not sure it is a good idea to hardcode a specific sourceforge mirror (mesh) in the build script.
there is yet another whole gaggle of threads around, discussing about sourceforge's mirror selection mechanism. Another script problem. I got so sick of it that I have a spare copy of the packages, and just manually load them into $ROOT/3rdparty/mingw/packages when needed.
- Now the good news is that MinGW is built! The script works well up until a path specification failure during build_oglft_mingw(), that I'll now work on.
- I am deeply ashamed however. The problem with my MinGW build was an environment variable setting, now deleted, that I'd make along time ago ( in .bashrc, so it held with every login! ) and I'd completely forgotten about it. I figured if Oliver could get a Debian build then Ubuntu would be fine, so I started to think about what might be wrong with my system and went back and looked at such things. So there you go ...... now I 'only' need the OGLFT and BOINC cross compiles! :-)
Wow, these environment variables are dangerous suckers .....
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: I've used the Cygwin
)
That's indeed likely. A great trouble here is that there is considerable depth in the toolchains that are downloaded with the packages, so I'm reluctant to dive in too deep there. I might solve my problem and unknowingly introduce another worse one.
As far as I can tell : the x86-mingw32-build.sh.conf ( and thus the patch for that ) can set eg.
option CFLAGS_FOR_RUNTIME -D__USE_W32_SOCKETS
and such things appear in the output of the build script, echoing the gcc command invocation. But that's at about line 4200+ so heaven knows what might precede that and yet be relevant.
Thanks for your thoughts :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
OK. I'm dying to release
)
OK. I'm dying to release something .... it's time to find out if it flies or I go down in flames. Where's my Nomex underwear ?! :-) :-)
So here is the linux version of work so far - sorry Windows and Mac users you'll have to wait for build script issues to settle. :-(
It's an ~ 11MB zip ( executable and images ) that I recommend downloading to a suitably empty directory, then unzip it and run :
[pre] graphics_app=einstein_SOLARSYSTEM_V0_1_graphics_i686-pc-linux-gnu[/pre]
I've shifted the initial craft position to bring the Earth into your immediate first view. Remember if you can't see the HUD it's probably because the window/screen dimensions are too small.
By all means report any problems/concerns whatsoever. Two files are created ( in the same directory as the executable ) that may give helpful error output :
[pre] stderrgfx.txt
solarsystem_stderr.txt[/pre]
When invoked from a terminal screen/window then other information is also emitted there.
I expect two main categories of issues:
- huge programming boners that I've made. Missing the bleeding obvious etc ...
- native graphics driver OpenGL support ....
Known minor issues :
- textures on polar caps of Earth and Sun don't quite cover ( small wedge missing )
- constellations coming alphabetically after Taurus yet to be incorporated
- glitches on multi-monitor systems
- being a debug build it has alot of code for that purpose, so it might be 'laggy' at times. Especially on resize as many of the underlying objects have to be destroyed and then reconstructed.
Now pretty much all visual or user-interface aspects are easily configurable during builds ie. colors, sizes, positions, speeds, keycodes, or whatever. Thus I would also be most grateful for any 'style' based feedback.
Cheers, Mike.
( edit ) Oh, and to satisfy GLPL2 the source code is referenced ( lower screen ) at GitHub, SolarSystem branch, tag name "V0.1" - try here
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: Suggestions ?
)
Yep, don't use x86-mingw32-build.sh :-) I stopped using it when I needed gcc 4 support and since then I use Debian's stock MinGW - works like a charm, e.g. for our Windows BRP science applications (including CUDA and OpenCL!). Shame on me though that I haven't yet ported this change back to the graphics framework! You should have told me earlier ;-)
I wonder, should I do this now? It would introduce an additional dependency on an existing MinGW installation on the cross-compile Linux host though.
Oliver
Einstein@Home Project
RE: sorry Windows and Mac
)
Ok, I'm now aware of the Windows build issue but how about Mac? What's the problem there?
Cheers,
Oliver
Einstein@Home Project
I was trying to build this
)
I was trying to build this for Win32 and Mac.
Oliver, I would appreciate it if you could do the mingw change soon, or at least tell us a workaround on how to modify the build script for a system that has the mingw-gcc installed.
The only problem I currently have on the Mac is that the freetype2 library (http://mesh.dl.sourceforge.net/sourceforge/freetype/freetype-2.3.5.tar.bz2) seems unavailable right now from sourceforge.
BM
[Edit]
got freetype from http://download.savannah.gnu.org/releases/freetype/freetype-2.3.5.tar.bz2
I'm not sure it is a good idea to hardcode a specific sourceforge mirror (mesh) in the build script.
[/Edit]
[Edit#2]
I can't get the BOINC compile (on Mac) to recognize the libjpeg of MAcPorts. Do your Makefiles honor CPPFLAGS and LDFlags from the environment, or just overwrite these?
[/Edit#2]
BM
Ok, and finally (that one's
)
Ok, and finally (that one's probably for Mike to fix):
[pre]
In file included from /Users/bema/Einstein-At-Home-Screensaver/src/framework/../solarsystem/SolarSystem.h:41,
from /Users/bema/Einstein-At-Home-Screensaver/src/framework/../solarsystem/SolarSystemS5R3.h:24,
from /Users/bema/Einstein-At-Home-Screensaver/src/framework/GraphicsEngineFactory.h:25,
from /Users/bema/Einstein-At-Home-Screensaver/src/framework/GraphicsEngineFactory.cpp:21:
/Users/bema/Einstein-At-Home-Screensaver/src/framework/../solarsystem/Simulation.h:41:31: error: HUDTextLineScroll.h: No such file or directory
[/pre]
Below is a short diff to the build script that made it work for me this far on the MAc:
[pre]
diff --git a/build.sh b/build.sh
index 6270835..e177eed 100755
--- a/build.sh
+++ b/build.sh
@@ -264,7 +264,7 @@ prepare_freetype()
echo "Retrieving Freetype2 (this may take a while)..." | tee -a $LOGFILE
cd $ROOT/3rdparty || failure
- wget http://mesh.dl.sourceforge.net/sourceforge/freetype/freetype-2.3.5.tar.bz2 >> $LOGFILE 2>&1 || failure
+ wget http://download.savannah.gnu.org/releases/freetype/freetype-2.3.5.tar.bz2 >> $LOGFILE 2>&1 || failure
tar -xjf freetype-2.3.5.tar.bz2 >> $LOGFILE 2>&1 || failure
rm freetype-2.3.5.tar.bz2 >> $LOGFILE 2>&1 || failure
# substitute old source tree
@@ -464,7 +464,7 @@ build_boinc()
chmod +x configure >> $LOGFILE 2>&1 || failure
cd $ROOT/build/boinc || failure
if [ "$1" == "$TARGET_MAC" ]; then
- export CPPFLAGS=-I/sw/include
+ export CPPFLAGS="-I/sw/include -I/opt/local/include $CPPFLAGS"
$ROOT/3rdparty/boinc/configure --prefix=$ROOT/install --enable-shared=no --enable-static=yes --disable-server --disable-client --with-apple-opengl-framework --enable-install-headers --enable-libraries --disable-manager --disabl
elif [ -d "/usr/local/ssl" ]; then
echo "Using local SSL library..." | tee -a $LOGFILE
[/pre]
BM
BM
RE: I was trying to build
)
Will do.
Most of the times it's a temporary issue with the mirrors, or they changed/removed the version entirely (needs to be updated in that case).
I think I extend, hence don't overwrite them.
Oliver
Einstein@Home Project
RE: RE: I can't get the
)
You do in the build script. See my patch.
BM
BM
Right, thanks. All fixed
)
Right, thanks. All fixed and/or updated.
I "discovered" my old mingw_gcc44 branch that already contains the necessary commits to use a standard MinGW installation - in my case the one provided by Debian. I don't know how well it translates to other Linux distributions. Give it a try.
Since your branch is based on our master you can simply merge it into your branch -- or just cherry-pick the two latest commits from master. Regarding the mingw_gcc44 branch I recommend you check it out locally and rebase it using your branch. This way you should get your branch with the required MinGW patches applied on top of it :-)
Please note that libxml2 might throw an error WRT libiconv when cross-compiling for Windows. This is a known issue I fixed on my build machine. I intend to fix this permanently in the build script itself shortly (this week?). In case you hit this one, bear with me for a few more days.
HTH,
Oliver
Einstein@Home Project
OK, thanks for the input
)
OK, thanks for the input guys. I should have spoken up sooner. ;-)
- HUDTextLineScroll class has been pushed to my GitHUb. Sorry 'bout that ....
- as regards
there is yet another whole gaggle of threads around, discussing about sourceforge's mirror selection mechanism. Another script problem. I got so sick of it that I have a spare copy of the packages, and just manually load them into $ROOT/3rdparty/mingw/packages when needed.
- Now the good news is that MinGW is built! The script works well up until a path specification failure during build_oglft_mingw(), that I'll now work on.
- I am deeply ashamed however. The problem with my MinGW build was an environment variable setting, now deleted, that I'd make along time ago ( in .bashrc, so it held with every login! ) and I'd completely forgotten about it. I figured if Oliver could get a Debian build then Ubuntu would be fine, so I started to think about what might be wrong with my system and went back and looked at such things. So there you go ...... now I 'only' need the OGLFT and BOINC cross compiles! :-)
Wow, these environment variables are dangerous suckers .....
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal