Hi Geoff, On Saturday, October 29, 2011 18:21:29 Geoff McLane wrote: > Thank you for your reply and ideas... and > hope I can answer some things regarding Windows... > And as usual, sorry in advance that this is so > long... So, my disclaimer is that I do not have any win32 system running. I just heared - even if also not explicitly targeted to you - some complaints that this is 'all not working'. That is also not the way I try to think about such problems. What I want is some help to find the real problem. What I can offer is asking questions and suggesting things. Proably with some background I also have also with win32 systems. But I do not own one and at work where I have access to some, I do not want to play flightgear.
> While I nearly always use 'shared' libraries in > Ubuntu, when offered, such DLL implementations > in Windows are just NOT so good... > > It means when you want to share the application > with some other Windows person, or even copy it to a > second, 3rd machine, you have to - > (a) pack all the DLLs with the EXE, and you/they > need to know how to set it up, or > (b) you have to go to whole distance and pass > them a Windows installer app, which will handle > all this placement for them... using like NSIS, > INNO, etc... Yes. I am aware of that. This is pretty much the same on *nix. It's just more unusual that you move built binaries from one machine to the other without a system installer. > Moreover even then, usually depending on the MSVC > version used, and the runtime chosen, there still > remains some incompatibilities even between the > various versions of Windows... Yep. But that does not change with a static build I think. Or do you also statically link against msvcrt? I believe you still need to make sure that the redestributible runtime is installed on the machine you use. Or alternatively unpack the msvcrt and friends into a directory named like the manifest hash beside the binary. Then the runtime is found even when not installed in the system. > As you point out, OSG does fully support using > static libraries, AND that support INCLUDES > pulling in the desired set of plugins... see > the USE_OSGPLUGIN(ac); MACRO... > > AND SimGear/FlightGear includes all this 'static' > support, just by defining OSG_LIBRARY_STATIC the > OSG macro pulls in the desired set of plugins... Ok, I did a quick grep over simgear and did not find this ... But it's in flightgear. Ok - I was not aware of that. > Now whether pthreads is still needed for SG/FG, > that I will have to check... maybe it is just > some residual, old code... Yes, for *nix. Since this is the primary thread library you need to use to start a thread on *nix. but on win32 this should not be needed. There is a native win32 implementation in OpenThreads as well as in osg. > Ok, quickly looking in src/Main/bootstrap.cxx, > I can see the code :- > #ifdef PTW32_STATIC_LIB > // Initialise static pthread win32 lib > pthread_win32_process_attach_np (); > #endif > so, if pthreads is NOT required then this > call should be REMOVED from the code. Ok. > Now back to OSG, I do NOT think the changes > I have had to make in the GUI have anything > at all to do with whether using shared or > static OSG... > > Yes, it does make a slight difference regarding > the plugins, since in the static case, this > set of plugins desired MUST be passed to the > linker at link time... about 6 or 10 of them... Yes, also it's not sufficient to just link with some parts of osg. 1. The order of the osg libraries gets important. 2. Some of them might itself depend on libraries that are just already linked with the dlls otherwise. These libraries must b included in the link process. I still believe that already some of the cmake tests regarding osg or simgear fails due to some of these problems. So all the hand changes you tell about are changes that just paper over such kind of problem I think. And sure these changes are overwritten by cmake all the time since they were never intented to be changed by the user. So if I understand the real problem, I am pretty sure cmake is a net win since plenty of build system stuff is now shared across *all* platforms. > But in windows, EACH of these variable MUST be setup > one by one, in the GUI... No, this must not happen. We need to find out what is going wrong here. This is the real reason of what is going wrong. > I have not done the counts exactly, but that is like > SimGear 25 x 3 items to setup > OSG 8 x 3 items to setup > PLIB 7 x 3 items to setup :-) Puh. I would never do that! Before you do so the first time, come here and ask for help! > RANT begins ;=() :-) You don't do any rants with the following. At least not to me. I hope that I did not sour too hars with the past mail ... > Then on 2010/10/19 Jame proposed cmake. His words > at the time - "These files are completely orthogonal > to the existing autoconf/automake build..." and "My > motivation for creating these was my Mac Xcode > projects..." and even asking developers to consider > updating CMakeFiles.txt when they changed the > Makefile.am, like some were already doing for the > MSVC vcproj files... I don't care for all the gui builders. But I still also think that having one common build system is good to have. Every now and then I changed the windows build files. But almost every time I just did miss that. Not to talk about James needs for apple. While there are still some system dependent things to care for, most simple build system changes will just come to all build systems using cmake. So while I still have some personal complaints against cmake, I do also think that it is a goo alterantive for plenty projects. > So I am most concerned about what this > will mean to windows builders. It is > absolutely NOT enough to just say cmake > is cross-system-compatible... So, yes it is. I still think so. I think you confuse 'cmake is bad' with 'there are still windows dependent problems'. Or more specific: 'there are sill windows specific problems with a static build'. And I must admit, I was not aware of any support for pure static builds together with osg. We do static osg for some commertial stuff at work, but it's just much more complicated and error prone than the default shared build. > I am sorry Mathias, this turned into a > general RANT ;=(( which has been building up > for a while... Certainly not in any way > directed at you... :) You are welcome. And even if I do not anymore show up too often, I do support having a common build system with cmake. Since you can see jenkins building win32 binaries, I think that we can reduce the problem to 'we currently miss support for fully static win32 builds.' So please help. And please do that step by step. ... I am sure descriptions what goes wrong get shorter this way. Does simgear recognize osg? Are all 3rd party libraries found by cmake? Are they correct? Which cmake configure test does fail and how can this be improoved to find the static libraries you need? Is the link complete? Do the test programs link correctly? May be this gives some hint on which libraries are missing without the need to go to the end of trying to link fgfs.exe. Are the debug libs correctly found? You told that you want them. This must all work without hand changing stuff that cmake resets on every configure step. That's so boring work that I still cannot believe that somebody thinks this is the normal case! Greetings Mathias ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
