[Radiance-dev] Radiance compiled with mingw gcc (windows)

[Georg Mischler]

Francesco wrote:
> Georg Mischler wrote:
>> We should create a seperate platform/mingw.cfg with
>> the parameters found. Francesco: Did you find any easy way to
>> tell the difference from within SCons/Python? We already have a
>> seperate *.cfg file for normal cygwin (using posix libraries),
>> but I don't remember how we figured out when to use that.
>
> Since the platform is recognised as "win32"
> I created my own platform\win32_custom.cfg

Creating an extra platform\mingw.cfg is the correct way to do it.
Those files are not just for each platform (despite the directory
name), they are for each compile environment.


>> What were the RAD_COMPAT entries?
>
> I've added only "fixargv0.c", and copied the actual file inside
> the utils and rt folders.

This belongs to the RAD_ARGSCOMPAT config variable, which puts
the compiled objects into librtargs.a.
The generic RAD_COMPAT is actually obsolete.


>>> I've just noticed I forgot to mention that I've also added
>>> libws2_32 (-lws2_32) to the list of linked libraries to get
>>> some programs compiled.
>>
>> What does this do? Is this a compatility layer added by mingw?
>
> I haven't understood well it either. It is the winsock library,
> so it may seem unrelated, but before adding it, the linker
> was complaining about many linking errors, and adding it solved the
> situation. I haven't investigated any further.

Ah, that are the calls to gethostname().
VC uses a lot of magic to fund libraries when you include
certain headers, so very few explicit linker directives are
necessary. With gcc, we need to be more specific.

I added a new variable RAD_SOCKETLIB, the contents of which are
always linked to when -lrtnet is also present. This removes the
-lws2_32 from the generic LINKFLAGS.


> The previous cygwin config file was working well, BTW ...

Yes, but it's doing the same things in much cleaner ways now.


> Cygwin already provides fseeko and ftello.

And here's the implementation:
  http://article.gmane.org/gmane.comp.gnu.mingw.user/11984
Unfortunately, fpos_t may be a struct on *some* Windows systems
(haven't found out which), and will then cause the build to fail.
But it seems reasonable to assume that this solution will work on
systems that support large files. It will probably end up in a
new file such as common/win_lfs.c.


Greg wrote:
> Then it's probable something is dying in the -f option processing
> that has nothing to do with fseeko().  I'm checking the library path
> with a call to getpath(), so if that was screwing up before, maybe
> it's screwing up during the -f processing as well.

Which means we need to check my Windows version of getpath().
Francesco, do you have a debugger available to trace through
this? Or does it get better if you specify fixargv0.c correctly
with the RAD_ARGSCOMPAT variable? Do you have the RAYPATH set
correctly? (for getrlibpath(), by default it uses ";c:\ray\lib")


-schorsch

-- 
Georg Mischler  --  simulations developer  --  schorsch at schorsch com
+schorsch.com+  --  lighting design tools  --  http://www.schorsch.com/