Thanks for reporting this problem.  I always wanted to try compiling
POV-Ray with msys but never managed to find some time for it...

> /mingw/bin/gcc -o mkg3states -I.././../zlib   -pipe -O3 -march=pentiumpro
> -mtune=pentiumpro -malign-double -minline-all-stringops     -I.
> -I../libtiff   ../libtiff/mkg3states.c
> C:/WINNT40/Profiles/SLSAND~1.RDG/LOCALS~1/Temp/cc0Eaaaa.o(.text+0x201):mkg3states.c:
> undefined reference to `getopt'

	The libtiff library always caused me trouble in rewritting the build
system, especially when dealing with cygwin support.  I'm not surprised that
it now fails with msys.  Libtiff should normally compile ../port/getopt.c
in this environment, but seems it either does not or something is screwed up.
	I'll try to solve the problem this week-end (no guaranty...)

	- NC

Post a reply to this message

In article <40e69680$1@news.povray.org> , Nicolas Calimet 
<pov### [at] freefr>  wrote:

>> - vsnprintf is unknown (whereas vsprintf is ok)
>
>  As Thorsten wrote, this is a sign of too old C library.  And
> reverting to the non-n version is not an option, nor is it to try to
> provide an alternate implementation.  It is very likely that I will
> just make configure stop with error if vsnprintf is not found.

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__;
    }

However, if this fails (and at least for gcc 3.3 on Mac OS X it does) you
will still have to perform various individual checks...

    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

> with builddir!=sourcedir

	Yes, I've learnt the lesson  :-)

> Then, I downloaded the sources without the bundeled libraries

	Eh ?  How can you download a package which does not exist ?  ;-)

> Running configure had some trouble: It detected pentiumpro optimization 
> for my AthlonXP. This is because $host=i686 and "uname -p" yields an error 
> because uname (at least on my debian system) does not know the option -p.

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

>     case "$(fgrep "model name" /proc/cpuinfo | head -1)" in
>       *Athlon*XP*)  etc ... ;;

	This is something I considered to do, but did not yet.
	I will consider it again as an alternative to 'uname -p'.

> especially note the "head -1" which is needed for SMP/HT 
> systems.

	Ah, right, good point.  Thanks.

> 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  :-)

> flags           : fpu vme de tsc msr pae mce cx8 sep mtrr pge mca cmov pat
> pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
> Especially note "sse".

	Note I'm already using these flags in configure.ac (in principle
you should get an -msse -fpmath=sse, don't you ?).

> However, I did not test the installation routines since I am always using 
> POVRay directly from the build directory.

	Rhoooo  ;-)

> Great compliment to the HTML documentation.

	The docs are not at all specific to the UNIX packages (only the
first chapter of course), and I'm not the one to thank for this kind of
improvements  :-)

> So, this was my feedback on _compiling_ the sources. I'll post something 
> about the sources itself in p.programming shortly.

	Note again that the official sources will be available in due course,
so I'd suggest starting such kind of discussion after they are released.

	Thanks for testing,
	- NC

Post a reply to this message

> 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