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

[anselmo at dream.unipa.it]

Hi Greg + Georg, and thanks!

I'm answering to the questions of both of you within
this message ...

Schorsch wrote:
> The only difficulty here is that while we're compiling and
> linking to the standard Windows libraries (apparently), the
> gcc in mingw expects other command line arguments than the
> VC compiler. 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

> Printing all items of env might produce better clues. Also, what
> does mingw put in os.name and sys.platform?

It puts "nt" and "win32". It is not like cygwin, that is a unix
system within windows. I compile from the standard windows C:\ prompt ...

>>> and had to manually add some extra RAD_COMPAT inside a couple
>>> of SConstruct files (maybe somebody can suggest a better
>>> CPPDEFINES line ...).
>
> What were the RAD_COMPAT entries?

I've added only "fixargv0.c", and copied the actual file inside
the utils and rt folders.

> I'm not sure if I understand this right now (but then, I just
> returned from Mongolia, so don't expect too much).

I had noticed the interesting Lighting Wiki sponsor before ;)

> I don't think your change breaks anything, but it's still not
> the nice thing to do. Instead of feeding an empty string (which
> results in a double width space in the command line) just pass
> only the remainder of the argument list to quoted_cmdline():
>
>   cmdstr = quoted_cmdline(cmdpath, av+1);
>
> (Now in CVS)
> I think this is save, because the first item will always be
> the name of the command, and if there are no arguments, then
> the second item will be NULL, which quoted_cmdline() should
> handle correctly (I don't have a Windows system at hand right
> now, though, so it's up to you to try...).

I was sure it was not an elegant solution. Tested and it works
and doesn't break anything. Thanks!

>> 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.

> I moved some of your stuff to (hopefully) more appropriate lines,
> and also corrected the other Windows config (VC6 and cygwin) in
> the same way.

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

>> BTW It looks like the mingw developer are going to add support for large
>> file system files at some point, probably later than sooner ...
>
> How are they planning to do this? They would have to extend the
> system libraries, as far as I can tell.

I don't know exactly the implementation details, but I guess so.
Cygwin already provides fseeko and ftello.

Greg wrote:
> The -o option should work of course, and I would like it to work.
> It's needed for other things.  If you change the line:
>
> static void closefile(void *p) { fclose((FILE *)p); }
> to:
> static void closefile(void *p) { fputs("C",stderr); fclose((FILE *)p); }
>
> You should get as many C's on your output as you have -o options.  If
> that's not happening, it means this call is not being made as it
> should be.  I'm trying it on my system now to make sure it's working
> here.

Unfortunately the call is not made when I use the -f switch.
It gets called only when I don't use the -f option.

One last thing, that should be unrelated with the other problems:
if run without any argument, rtcontrib segfaults.

Thank you,

Francesco