Trying to cross-compile POV-Ray 3.6.1. Build platform: cygwin. I'll 
leave you curious on what the host platform is.

As far as I know, the correct way to set it is using --host on the 
configure script. That makes the configure script print this warning 
(and then continue happily):

configure: WARNING: If you wanted to set the --build type, don't use 
--host. If a cross compiler is detected then cross compile mode will be 
used.

So I'm not sure if I'm really doing it right.


After configuring POV-Ray itself, it configures zlib. All works fine. 
Then libpng, which also works fine. When it arrives to libjpeg, I get this:

checking for gcc... no
checking for cc... no
configure: error: no acceptable cc found in $PATH

Apparently it doesn't support --host. Maybe the fact that it was made 
with autoconf 1.12 (and we're up to 2.61) has something to do :) Calling 
it with 'CC=platform-gcc' as an argument makes it work correctly.

After libjpeg fails, POV-Ray's configure script *continues*, and starts 
tiff's configure. That *also* fails, and POV-Ray's configure still says 
it's all done and ready to run make! I think there should be checks for 
sub-configures failing. Maybe starting the configure script of the next 
library anyway (so the user can solve all problems at once before trying 
again) but at the end giving a message that it's *not* all good and ready.

Second roadblock. Libtiff's problem is similar to libjpeg: it can't find 
cc. Running it with --host, it says it's not even a valid option. it 
doesn't even support giving it CC=platform-gcc as an argument, I have to 
set it on the environment before running configure. I *just* noticed I 
can also use --with-CC=platform-gcc. And I can pass the platform name as 
an argument (without any switch), but that doesn't make it use the 
correct CC name, so I don't know what it's useful for.

Now its configure script works fine. And third roadblock. libtiff's 
makefile has a terrible habit of compiling tools (using the 
cross-compiler!) and trying to run them; like mkversion, and another 
tool to make a lookup table or something. Of course, this doesn't work: 
"cannot execute binary file". I was able to manually create tiffvers.h, 
but I won't be doing the same with the lookup table...

Fine, I get the idea. Libtiff won't cross-compile without a lot of hacking.

Feature request: let me disable it. It would make sense if I could 
disable tiff support completely, giving an error when that file format 
is used in an image_map or similar. Or what if I want a build without 
*any* image support, for rendering RSOCPs on an embedded device?

Post a reply to this message

> Trying to cross-compile POV-Ray 3.6.1.

	Good idea  :-)

> Maybe the fact that it was made 
> with autoconf 1.12

	Yes, very likely.  The jpeg library is rather old anyway.

> I think there should be checks for 
> sub-configures failing.

	This is a known problem that, IIRC, has been fixed for a 3.6.2 that
we unfortunately had no time to release yet  :-(

> Second roadblock. Libtiff's problem is similar to libjpeg

	The tiff library provided in POV's source distro is 3.6.1 IIRC, and
this one is rather ugly as far as configuration is concerned.  The latest
3.8.x series of libtiff are far better here.

> Now its configure script works fine. And third roadblock. libtiff's 
> makefile has a terrible habit of compiling tools (using the 
> cross-compiler!) and trying to run them; like mkversion, and another 
> tool to make a lookup table or something. Of course, this doesn't work

	Yeah, I had this kind of nightmare to solve when trying to configure
libtiff from within POV's configuration.  So no surpises here  :-/

> Fine, I get the idea. Libtiff won't cross-compile without a lot of hacking.

	I'd bet so.

> Feature request: let me disable it.

	Then try the 3.7 unix sources that have been made available today  :-)
	(BTW, the external libs are no longer included in the 3.7 unix sources)

	- NC

Post a reply to this message

>> Trying to cross-compile POV-Ray 3.6.1.
> 
>     Good idea  :-)

Is that sarcastic? :) Technically, I don't even have access to the 
platform I'm targeting, so there is no way I can do a native compilation.

>> Second roadblock. Libtiff's problem is similar to libjpeg
> 
>     The tiff library provided in POV's source distro is 3.6.1 IIRC, and
> this one is rather ugly as far as configuration is concerned.  The latest
> 3.8.x series of libtiff are far better here.

libtiff.org says latest version is 3.6.1...

>> Feature request: let me disable it.
> 
>     Then try the 3.7 unix sources that have been made available today  :-)
>     (BTW, the external libs are no longer included in the 3.7 unix sources)

Great! I'll give that a try.

Can threading be disabled too? Preferably to a point where I don't need 
to play around with Boost at all?

Uh, why am I asking at all... **downloads and checks by himself**

Post a reply to this message

> Is that sarcastic? :)

	Not at all, the install docs in the 3.6 source distro clearly mention
about cross-compiling -- i.e. that it would be nice someone tries it  :-)

> libtiff.org says latest version is 3.6.1...

	You have to dig into it a bit more.  Most Linux distro come with 3.8.2
which was released at least a year or two ago.

> Can threading be disabled too?

	No.

	- NC

Post a reply to this message

I couldn't figure out how to even start compiling the boost stuff. And 
somebody who built it for the same platform I'm trying told me it was a 
big pain to get it working. So I'll go back to trying with 3.6.1.


>> libtiff.org says latest version is 3.6.1...
> 
>     You have to dig into it a bit more.  Most Linux distro come with 3.8.2
> which was released at least a year or two ago.

I found it. It uses autoconf, yay! Configure went perfectly in first 
try, but make failed at this point:

http://www.pastebin.ca/921153

Apparently somebody has a precompiled libtiff I could use...

-- 
Nicolas

PS: yes, I realize that paste somewhat gives away the platform I'm 
targeting.

Post a reply to this message

> Apparently somebody has a precompiled libtiff I could use...

I got *much* closer to success. All of POV-Ray, zlib, png, jpeg, fully 
configured and compiled. Using a precompiled libtiff. On the very last 
linking step:

ld: Undefined symbols:
setjmp(int*)
longjmp(int*, int)
___eprintf
collect2: ld returned 1 exit status
make[2]: *** [povray] Error 1
make[2]: Leaving directory `/home/Nicolas/povray-3.6.1/unix'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Nicolas/povray-3.6.1'
make: *** [all] Error 2

Post a reply to this message

> I got *much* closer to success. All of POV-Ray, zlib, png, jpeg, fully 
> configured and compiled. Using a precompiled libtiff. On the very last 
> linking step:
> 
> ld: Undefined symbols:
> setjmp(int*)
> longjmp(int*, int)
> ___eprintf

Even closer! It was trying to link to C++ versions of setjmp and longjmp 
(note there is an argument list and there is no leading underscore). I 
had to add extern "C" in a few places. Now it's only complaining about 
___eprintf.

Post a reply to this message

>> I got *much* closer to success. All of POV-Ray, zlib, png, jpeg, fully 
>> configured and compiled. Using a precompiled libtiff. On the very last 
>> linking step:
>>
>> ld: Undefined symbols:
>> setjmp(int*)
>> longjmp(int*, int)
>> ___eprintf
> 
> Even closer! It was trying to link to C++ versions of setjmp and longjmp 
> (note there is an argument list and there is no leading underscore). I 
> had to add extern "C" in a few places. Now it's only complaining about 
> ___eprintf.


Good news: complete success! I now have a POV-Ray binary that should run 
on the iPhone or iPod touch.

Bad news: in my attempt to jailbreak my iPod touch to try my 
compilation, I think I bricked it. Gah!

(when replying to this message, please post only to .programming if 
replying the good news, and only to .off-topic if replying the bad news)

Post a reply to this message

Nicolas Alvarez wrote:
> I couldn't figure out how to even start compiling the boost stuff.

	Did you try the --with-boost-src=DIR option of POV's configure?
I'd be quite interested to see whether it works for cross-compiling.

	- NC

Post a reply to this message

And lo on Thu, 28 Feb 2008 00:51:45 -0000, Nicolas Alvarez  
<nic### [at] gmailisthebestcom> did spake, saying:


>
> Bad news: in my attempt to jailbreak my iPod touch to try my  
> compilation, I think I bricked it. Gah!

Damn you Microsoft for your propri... oh wait sorry; reflex action.  
Ahem... well done to Apple for ensuring the quality of their fine, fine  
products.

-- 
Phil Cook

--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com

Post a reply to this message