Nicolas Calimet <pov### [at] freefr> wrote:
> > Suffice it to say that the simple ./configure will not work unless one uses
> > the non-standard GNU revision of sed.
>  > [...]
>  > configure.gnu: editing libtiff/Makefile sed: command garbled:
>  > s,^tiffvers.h:.*,, ; s,${SRCDIR}/tiffvers.h,tiffvers.h,g
>
>  Sorry, but the problem is not using GNU sed or not, it is that your
> stock sed is buggy.

This ?

$ which sed
/usr/xpg4/bin/sed

This sed is buggy?

I guess I have to go and see if there is a bug filed against it but somehow
I doubt it.

> > Looks like the build process is heavily
> > tied to Linux and GNUish things.
>
>  Not a all, please read the "Compatibility" section of the INSTALL file.
> Solaris is usually known to be a problematic environment.

Problematic ?  Old revs of POV-Ray were much easier to deal with .. back in
1999 or so.  How very odd.

> > CC  -O3   -L/usr/openwin/lib -R/usr/openwin/lib  -o povray  svga.o unix.o
> > xwin.o ../source/libpovray.a ../source/base/libbase.a
> > ...../source/frontend/libfrontend.a  -ltiff -ljpeg -lpng12 -lz -lXpm -lsocket
> > -lnsl  -lSM -lICE -lX11 -lm
> > Undefined                       first referenced
> >  symbol                             in file
> > int UNIX_allow_file_write(const char*,unsigned)
> > ...../source/libpovray.a(pov_util.o)
> > int UNIX_allow_file_read(const char*,unsigned)
> > ...../source/libpovray.a(pov_util.o)
> > ld: fatal: Symbol referencing errors. No output written to povray
>
>  This problem has been reported before and is archived here:

http://news.povray.org/povray.bugreports/thread/%3Cugl011lbbalv4oq1q9in1rh157vm6i7j7n%404ax.com%3E/

Oh excellent .. a documented bug.

OKay .. I see this :

   This is because the declaration in the .h file does not match the
   intended definition in the .cpp file. g++ does not care about the const
   restriction.

Probably something that g++/gcc ignores.
I know that when I tried the build I saw literally thousands of warnings.

> > Since this looks like the final linking stage I will assume that my
> > LD_OPTIONS did not get passed along.  The absent "int
> > UNIX_allow_file_write(const char*,unsigned) " must be in some library
> > somewhere.
>
>  No, this is a bug in unix.cpp: simply remove the two 'const' in the
> the following function definitions:
>
> int UNIX_allow_file_read (const char *Filename, const unsigned int FileType)
> int UNIX_allow_file_write (const char *Filename, const unsigned int FileType)
>
>  so that you get instead:
>
> int UNIX_allow_file_read (const char *Filename, unsigned int FileType)
> int UNIX_allow_file_write (const char *Filename, unsigned int FileType)
>

Let me give that a try and see how things go.  Hopefully I do not need to do
a "make distclean" and start over.  Actually, since I ran the "./configure"
from a directory other than the source directory I can just kill it and
start over :

Since I am doing builds for two architectures I am not building "in place"
but from another directory at the same level as the source.

$ pwd
/export/medusa/dclarke/build/povray/povray-3.6.1-sparc
$ cd ..
$ rm -rf povray-3.6.1-sparc
$ mkdir povray-3.6.1-sparc
$ cd povray-3.6.1-sparc

I'll see if I can find and edit that source :

$ find ../povray-3.6.1 -type f -name unix.cpp
.../povray-3.6.1/unix/unix.cpp

OKay .. so I then do ... at line 1896 there ...

/**************** buggy line ****************
int UNIX_allow_file_read (const char *Filename, const unsigned int FileType)
 ********************************************/
int UNIX_allow_file_read (const char *Filename, unsigned int FileType)

Then again at line 1972 ...

/******************** buggy line ****************
int UNIX_allow_file_write (const char *Filename, const unsigned int
FileType)
 ************************************************/
int UNIX_allow_file_write (const char *Filename, unsigned int FileType)

I then run ../povray-3.6.1/configure etc etc again and all goes well.

Now things fail again at this point because /usr/xpg4/bin/make somehow does
not work.  Neither does the version of make in /usr/ccs/bin/make but,
strangely, GNU make ver 3.81 does seem to work magically even though these
other two ( highly standards compliant versions ) seem to fail.

But when I run gmake the whole thing seems to build while emitting scads of
warning about everything one can imagine.

Looks like we have linkage !

CC  -O3   -L/usr/openwin/lib -R/usr/openwin/lib  -o povray  svga.o unix.o
xwin.o ../source/libpovray.a ../source/base/libbase.a
.../source/frontend/libfrontend.a  -ltiff -ljpeg -lpng12 -lz -lXpm -lsocket
-lnsl  -lSM -lICE -lX11 -lm
gmake[2]: Leaving directory
`/export/medusa/dclarke/build/povray/povray-3.6.1-sparc/unix'
gmake[2]: Entering directory
`/export/medusa/dclarke/build/povray/povray-3.6.1-sparc'
cat ../povray-3.6.1/povray.ini.in | sed
"s,__POVLIBDIR__,/export/medusa/dclarke/local/sparc/share/povray-3.6,g" >
../povray.ini
gmake[2]: Leaving directory
`/export/medusa/dclarke/build/povray/povray-3.6.1-sparc'
gmake[1]: Leaving directory
`/export/medusa/dclarke/build/povray/povray-3.6.1-sparc'
$ find . -type f -name povray
../unix/povray
$ file ./unix/povray
../unix/povray:  ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
Required, dynamically linked, not stripped
$ ldd ./unix/povray
        libtiff.so.3 =>  /export/medusa/dclarke/local/sparc/lib/libtiff.so.3
        libjpeg.so.62 =>         /opt/csw/lib/libjpeg.so.62
        libpng12.so.0 =>         /opt/csw/lib/libpng12.so.0
        libz.so =>       /opt/csw/lib/libz.so
        libXpm.so.4.11 =>        /opt/csw/lib/libXpm.so.4.11
        libsocket.so.1 =>        /lib/libsocket.so.1
        libnsl.so.1 =>   /lib/libnsl.so.1
        libSM.so.6 =>    /usr/openwin/lib/libSM.so.6
        libICE.so.6 =>   /usr/openwin/lib/libICE.so.6
        libX11.so.4 =>   /usr/openwin/lib/libX11.so.4
        libm.so.1 =>     /lib/libm.so.1
        libCstd.so.1 =>  /lib/libCstd.so.1
        libCrun.so.1 =>  /lib/libCrun.so.1
        libc.so.1 =>     /lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libXext.so.0 =>  /usr/openwin/lib/libXext.so.0
        /usr/lib/cpu/sparcv8plus/libCstd_isa.so.1
        /usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
$

I have the libtiff in an odd location for this "test" build.

Wow .. now comes the really hard part, is there a test scene file that
always reports the same output data byte for byte ?  Some way to confirm
the accurate functionality of the resultant binary that I have here ?

I do have POV-Ray 3.6.1 built on a PowerPC machine here running Fedora Core
4 and I had to build a nearly complete tool chain to get that done.  It
works and if I compare the output from that to this should I expect
agreement if I do not use antialiase options or jitter or any sort of
random noise?

I guess I am asking .. is there a way to verify functionality ?

Lastly .. thank you very much ... you made the long and tortorous
frustrating process possible.

Dennis

Post a reply to this message