> you could also test if a ISO C 1999 standard C library is present

	I guess autoconf already has such a macro, I'll check it.

	- NC

Post a reply to this message

Wolfgang Wieser wrote:
> 
> Great compliment to the HTML documentation. Especially the links make it 
> much better to navigate and the index for searching will eliminate the 
> need for "grep xyz -r doc/" in many cases. 

Note that for fast search for keywords in the docs you can use:

http://www.tu-bs.de/%7Ey0013390/povdoc/index.html

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Nicolas Calimet wrote:

>> Then, I downloaded the sources without the bundeled libraries
> 
> Eh ?  How can you download a package which does not exist ?  ;-)
> 
The first build was on my universtiy account. 
Then, I tar'ed the sources without docu and examples to download 
it onto my home box. I don't want to dl 8M using a 56k modem, you know...

> Yes, that's a problem currently.  Note the p4 and Athlon XP optimizations
> were added very lately in configure.ac, and I didn't try to make them work
> in all situations (e.g. FreeBSB seems to report "i386" for an Athlon XP,
> which means there is currently no chance to optimize much for it although
> I included some basic support for FreeBSD with i686...)
> 
Yes, FreeBSD will always report "i386" for the Intel-x86 family. 

>> I'd suggest to use the /proc/cpuinfo primarily if we're not
>> cross-compiling and /proc/cpuinfo is available.
> 
> Damn I forgot cross-compiling here, thanks again !
> BTW, are you able to test the build system in a cross-compiling
> environment ?  INSTALL says I'd be glad to see if it works  :-)
> 
Since I have only x86 systems at university and at home, I sadly 
cannot test cross compiling. (Well, I also have 8bit uControllers 
with 2..64kb flash here but that's nothing worth trying :)

> Note I'm already using these flags in configure.ac (in principle
> you should get an -msse -fpmath=sse, don't you ?).
> 
Yes, the -fpmath=sse was added. However, I made some experiments 
with gcc-3.2 or 3.3 and that showed that code got slightly slower 
with these. But this may have changed with gcc-3.4 and also depend 
on the used processor. 

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:

> BTW, as a shortcut to testing for various standard library functions
> existing, you could also test if a ISO C 1999 standard C library is
> present if you test that __STDC_VERSION__ is equal *or* greater than
> 199901L (make sure you compile it as C not C++ code, that is, use a ".c"
> rather than a ".cpp" extension and make sure to call a C not the C++
> compiler) i.e. with
> 
>     int main()
>     {
>         return __STDC_VERSION__;
>     }
> 
This is probably a bad idea. It looks like __STDC_VERSION__ is significantly 
larger than 128. Some UNIX systems use only 1 byte to store the exit 
code of a program and hence, this will fail on these systems. 

I'd use a printf() statement instead. 

Wolfgang

Post a reply to this message

In article <40e6ae1c@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> This is probably a bad idea. It looks like __STDC_VERSION__ is significantly
> larger than 128. Some UNIX systems use only 1 byte to store the exit
> code of a program and hence, this will fail on these systems.

Then those systems are not compatible even with ANSI C. -- Too bad, we do
not support such outdated systems!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

> In article <40e6ae1c@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>> This is probably a bad idea. It looks like __STDC_VERSION__ is
>> significantly larger than 128. Some UNIX systems use only 1 byte to store
>> the exit code of a program and hence, this will fail on these systems.
> 
> Then those systems are not compatible even with ANSI C. -- Too bad, we do
> not support such outdated systems!
> 
OOPS Thorsten: 

FreeBSD (as e.g. also used inside a Mac computer) is most likely 
such a system!

me@x86-freebsd1# sh -c "exit 2000" ; echo $?
208
...whic is the LSByte of 2000. 

And there are others, too. 

Wolfgang

Post a reply to this message

In article <40e6c587@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> FreeBSD (as e.g. also used inside a Mac computer) is most likely
> such a system!
>
> me@x86-freebsd1# sh -c "exit 2000" ; echo $?
> 208
> ...whic is the LSByte of 2000.
>
> And there are others, too.

No, it is most likely just the shell that is broken (given the source of the
shells in most free Unix distributions, this is hardly surprising).  Try
something like

#include <stdlib.h>
#include <stdio.h>
int main(int ac, char **av)
{
    printf("Result: %d\n", system(av[1]));
    return 0;
}

This should work and demonstrate that the system works correctly and only
the shell is broken.  Then file a bug report at the appropriate place.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

> No, it is most likely just the shell that is broken (given the source of
> the
> shells in most free Unix distributions, this is hardly surprising).  
>
First of all, this is simply wrong, see below. 

But even in case it were true, it seems to me that this does not match 
the problem because the configure script is being interpreted by a shell. 

> Try 
> something like
> 
> #include <stdlib.h>
> #include <stdio.h>
> int main(int ac, char **av)
> {
>     printf("Result: %d\n", system(av[1]));
>     return 0;
> }
> 
Okay, and if you read the man page you knew the exit code of system() 
is that of wait(2) or waitpid(2) which is a plain integer storing the 
exit code in the least significant byte accessible using 
WEXITSTATUS(status). 
And the other bytes store things like the signal which killed the program. 

I just verified that the code presented by you above will NOT work as you 
expect on: 
  Darwin-PPC (MacOS-X)
  Linux-ix86
  FreeBSD-ix86
  NetBSD-ix86
  Solaris-5.9-ix86
(Nicolas: maybe I could run some checks for you on these boxes. 
I forgot that in my previous answer; but I doubt I can test cross-compiling 
using these.)

All these systems (and probably most other UNICes) behave in the way I 
described. 

> This should work and demonstrate that the system works correctly and only
> the shell is broken.  Then file a bug report at the appropriate place.
> 
OOPS... You'd better test yourself before posting :p

Wolfgang

Post a reply to this message

In article <40e6df2c@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> I just verified that the code presented by you above will NOT work as you
> expect on:
>   Darwin-PPC (MacOS-X)
>   Linux-ix86
>   FreeBSD-ix86
>   NetBSD-ix86
>   Solaris-5.9-ix86
> (Nicolas: maybe I could run some checks for you on these boxes.
> I forgot that in my previous answer; but I doubt I can test cross-compiling
> using these.)

I assume you tried with a shell which was already pointed out as broken.
Then maybe you are just incompetent to run the test because on a FreeBSD
5.2-CURRENT as well as on Mac OS X 10.3.4 a simple program like

int main()
{
        return 12345;
}

will yield the correct result when executed by system().

> Okay, and if you read the man page you knew the exit code of system()
> is that of wait(2) or waitpid(2) which is a plain integer storing the
> exit code in the least significant byte accessible using
> WEXITSTATUS(status).

Well, given that a man-page is documentation of the state of the system you
have, not a specification, that is completely irrelevant for the correctness
of my statement.  ANSI/ISO C specifies the system function to return an
integer "int" and programs return an "int".  Neither wait nor waitpid are
part of ANSI/ISO C, they are some random Unix functions that ave nothing to
do with ANSI or ISO C.  Thus, any system that for whatever reason cannot
fulfill said specification of an international standard does not comply to
it.  It is of course nice that they document such a limitation.

As such, any such system cannot be expected to be fully supported by
POV-Ray.  Of course, that does by *no* means imply POV-Ray will not run on
such a system or that POV-Ray cannot be compiled on such a system.  The only
relevant point is that if you run on a system unable to support ANSI/ISO C,
you got the problem, not the POV-Team.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

> I assume you tried with a shell which was already pointed out as broken.
> Then maybe you are just incompetent to run the test because on a FreeBSD
> 5.2-CURRENT as well as on Mac OS X 10.3.4 a simple program like
> 
No. On all systems mentioned above, I tried using the following programs: 

-----<test.c>------
#include <stdlib.h>
#include <stdio.h>
#include <sys/wait.h>
int main(int ac, char **av)
{
  int rv=system("./test2");    
  printf("Result: %x %x\n", rv,WEXITSTATUS(rv));
  return 0;
}
-----<test2.c>------
#include <stdio.h>

int main()
{
  printf("Here we are\n");
  return(0x1aa);
}
--------------------

And the result is what I described. 

> int main()
> {
>         return 12345;
> }
> 
> will yield the correct result when executed by system().
> 
This is not the case on any system I tested (Darwin-PPC, Linux-ix86,
FreeBSD-ix86, NetBSD-ix86, Solaris-5.9-ix86). 
Not even with magic number 12345 :)
You might exactly specify the system you are referring to. 

> As such, any such system cannot be expected to be fully supported by
[snipped following arrogance from Thorsten-Froehlich]

Wolfgang

Post a reply to this message