Nicolas Calimet <pov### [at] freefr> wrote:
[snip]
>  Thanks for testing the new build system of POV-Ray 3.6 for UNIX!
>
>  - Nicolas Calimet

I'm trying a compile under MSys (minimal shell system for MinGW).

Clean install of msys-1.0.10, gcc-3.4.0 most recent versions of necessary
packages.

../configure -without-x -without-svga ...

configures fine.

Running make is fine until

/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'
C:/WINNT40/Profiles/SLSAND~1.RDG/LOCALS~1/Temp/cc0Eaaaa.o(.text+0x24d):mkg3states.c:
undefined reference to `getopt'
C:/WINNT40/Profiles/SLSAND~1.RDG/LOCALS~1/Temp/cc0Eaaaa.o(.text+0x257):mkg3states.c:
undefined reference to `optind'
C:/WINNT40/Profiles/SLSAND~1.RDG/LOCALS~1/Temp/cc0Eaaaa.o(.text+0xcd0):mkg3states.c:
undefined reference to `optarg'
C:/WINNT40/Profiles/SLSAND~1.RDG/LOCALS~1/Temp/cc0Eaaaa.o(.text+0xce2):mkg3states.c:
undefined reference to `optarg'
collect2: ld returned 1 exit status
make[3]: *** [tif_fax3sm.c] Error 1
make[3]: Leaving directory `/c/mike/povray-3.6/libraries/tiff/libtiff'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/c/mike/povray-3.6/libraries'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/c/mike/povray-3.6'
make: *** [all] Error 2

For some reason it doesn't seem to be finding <getopt.h> although this
should be in the include chain: "port.h" -> <unistd.h> -> <getopt.h>

Hmm ... even if I explicitly #include <getopt.h> I still get the same
errors.

Any ideas anyone?

Mike Andrews.

Post a reply to this message

In article <Xns951A8C68E5428jgrimbertmeandmyself@203.29.75.35> , Le Forgeron
<jgr### [at] freelocalhost>  wrote:

> Ok, downloaded and testing... on solaris 2.5.1, gcc 3.3.2, sparc-cpu
>
> Problem are:
> - vsnprintf is unknown (whereas vsprintf is ok)

Note that this suggest you have an extremely outdated standard C library.
vsnprintf has been part of the ISO C standard since 1999.

    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

> In article <Xns951A8C68E5428jgrimbertmeandmyself@203.29.75.35> , Le
> Forgeron <jgr### [at] freelocalhost>  wrote:
> 
>> Ok, downloaded and testing... on solaris 2.5.1, gcc 3.3.2, sparc-cpu
>>
>> Problem are:
>> - vsnprintf is unknown (whereas vsprintf is ok)
> 
> Note that this suggest you have an extremely outdated standard C
> library. vsnprintf has been part of the ISO C standard since 1999.
> 
>     Thorsten

Agreed (and the X11 include (openwin) which are not ANSI C compliant is 
the biggest problem...)
Solaris 2.5.1 is really an old system.
Nevertheless, configure tests for vsprintf... it should also for 
vsnprintf, shouldn't it ?

I would say vs(n)printf is not very significant bug.

But being unable to configure when X is present but not wanted (or 
compatible, but C++ hates K&R syntax... so better compiling povray 
without X11 at all for me) is the real problem.
(And might not be limited to my solaris...)

I'll be offline for the weekend (which start right now!)


-- 




l'habillement, les chaussures que le maquillage et les accessoires.

Post a reply to this message

Mike Andrews wrote:
> C:/WINNT40/Profiles/SLSAND~1.RDG/LOCALS~1/Temp/cc0Eaaaa.o(.text+0x201):mkg3states.c:
> undefined reference to `getopt'

    [...]

> For some reason it doesn't seem to be finding <getopt.h> although this
> should be in the include chain: "port.h" -> <unistd.h> -> <getopt.h>
> 
    You don't have "getopt" in you libraries.
    It was not a problem with the include.
    May be adding -lgetop will help...

Post a reply to this message

Thierry Boudet <oul### [at] chezcom> wrote:
> Mike Andrews wrote:
> >
C:/WINNT40/Profiles/SLSAND~1.RDG/LOCALS~1/Temp/cc0Eaaaa.o(.text+0x201):mkg3states.c:
> > undefined reference to `getopt'
>
>     [...]
>
> > For some reason it doesn't seem to be finding <getopt.h> although this
> > should be in the include chain: "port.h" -> <unistd.h> -> <getopt.h>
> >
>     You don't have "getopt" in you libraries.
>     It was not a problem with the include.
>     May be adding -lgetop will help...

Hi Thierry,

I should have noticed that it was at the link stage rather than at compile!
It's obviously been much too long since I did any serious compilation ...

I got PoV to compile first time with Cygwin so I not too bothered at the
moment :-) but I'll try to have another look at Mingw compiling over the
weekend.

Mike.

Post a reply to this message

Nicolas Calimet wrote:

> A beta version of the source distribution of POV-Ray 3.6 for UNIX is
> now available for download.  
>
Great! 

Just compiled it on a SuSE P4 with builddir!=sourcedir and 
--without-svga. Everything went fine. 

Then, I downloaded the sources without the bundeled libraries (well, I 
do not want to discuss this one here, sigh) to my home box. 

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. 

One could do something like: 
  if test -f /proc/cpuinfo ; then
    case "$(fgrep "model name" /proc/cpuinfo | head -1)" in
      *Athlon*XP*)  etc ... ;;
      ...)
    esac
  fi

(The fgrep string will be 
"model name      : AMD Athlon(tm) XP processor 1700+"
in my case; especially note the "head -1" which is needed for SMP/HT 
systems.)

I'd suggest to use the /proc/cpuinfo primarily if we're not cross-compiling 
and /proc/cpuinfo is available. It gives easiest access to the supported 
extensions, too: 
bash# fgrep flags /proc/cpuinfo 
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". 

Here is a list of accessible hardware: 

--P4:--
model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
--AthlonXP:--
model name      : AMD Athlon(tm) XP processor 1700+
flags           : fpu vme de tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
--P3:--
model name      : Pentium III (Coppermine)
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
--P1:--
model name      : Pentium 75 - 200
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
-----------

So, for now, I reverted to using --disable-optimiz and passing my own CFLAGS 
and CXXFLAGS which worked as expected. 

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

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. 

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

Wolfgang

Post a reply to this message

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

> How the hell do you disable X Window display ?
> Retrying with ./configure --without-x ...
> Failed
> Retrying with ./configure --with-x=no ...
> Ditto.

	Thanks for reporting.
	Actually the option works (in either way shown above) on the systems
I could try it.  However it does not on your system, meaning that some test
is not robust enough.  The fix is very simple, so I'm confident it will work
next time for you.

	- NC

Post a reply to this message

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