Okay, folks -- I'm officially puzzled here.

I've broken the Unix build process, but for the sake of my life can't
figure out /how/. Here's the change by which I broke it:

https://github.com/POV-Ray/povray/tree/fdcb3676507e8907922dfc6dace95d449ae7860f

And here are the devastating results:

https://semaphoreci.com/pov-ray/povray/branches/master/builds/5

Somehow it seems that the definitions in povmscpp.cpp (and other .cpp
files in the ~/source/povms subdirectory) are no longer properly linked
into ~/source/libpovray.a for /some/ reason.

Someone help me out here. Plz.

Post a reply to this message

Am 28.01.2016 um 06:38 schrieb clipka:
> Okay, folks -- I'm officially puzzled here.
> 
> I've broken the Unix build process, but for the sake of my life can't
> figure out /how/. Here's the change by which I broke it:
> 
> https://github.com/POV-Ray/povray/tree/fdcb3676507e8907922dfc6dace95d449ae7860f

Ah, never mind -- got it sorted out. In a sense that commit didn't break
anything, it just revealed a pre-existing error in the code.

Post a reply to this message

Le 28/01/2016 06:38, clipka a écrit :
> Okay, folks -- I'm officially puzzled here.
>
> I've broken the Unix build process, but for the sake of my life can't
> figure out /how/. Here's the change by which I broke it:
>
> https://github.com/POV-Ray/povray/tree/fdcb3676507e8907922dfc6dace95d449ae7860f
>
> And here are the devastating results:
>
> https://semaphoreci.com/pov-ray/povray/branches/master/builds/5
>
> Somehow it seems that the definitions in povmscpp.cpp (and other .cpp
> files in the ~/source/povms subdirectory) are no longer properly linked
> into ~/source/libpovray.a for /some/ reason.
>
> Someone help me out here. Plz.
>

Such error at link stage are usually due to:
  * a failure to compile some code
  * an ordering problem with multiple libraries on the linker command

Did you start with a clean environment ? Previously compiled files might 
not have been recompiled and might miss a deep change of mapping.

If you moved some files, was the Makefile redone ?

About the ordering of libraries, when libA would need some part of libB, 
libA must appears before libB. But if libB needs also some code of libA, 
you got a problem of circular dependencies which can make it difficult 
to solve: the linker will extract only the needed symbol from libA due 
to the previous code (main or other *.o object) and get a list of needed 
symbols. then it close forever libA and search libB to extract the still 
needed symbols and might get more needed symbols too. rinse & repeat for 
the next library until the end of the list.

Post a reply to this message

Am 28.01.2016 um 09:52 schrieb Le_Forgeron:

> Such error at link stage are usually due to:
>  * a failure to compile some code
>  * an ordering problem with multiple libraries on the linker command
> 
> Did you start with a clean environment ? Previously compiled files might
> not have been recompiled and might miss a deep change of mapping.

The error was first brought to my attention by Semaphore, one of the
automated build services I've set up for our GitHub repo. They do start
with as clean an environment as you can possibly imagine.

> About the ordering of libraries, when libA would need some part of libB,
> libA must appears before libB. But if libB needs also some code of libA,
> you got a problem of circular dependencies which can make it difficult
> to solve: the linker will extract only the needed symbol from libA due
> to the previous code (main or other *.o object) and get a list of needed
> symbols. then it close forever libA and search libB to extract the still
> needed symbols and might get more needed symbols too. rinse & repeat for
> the next library until the end of the list.

Are you sure that's what's happening? Because last time I checked, there
is no problem linking two libraries into one executable even if they
recursively call each other. And I don't think it can't get any more
interlocked than that.


No, it was an entirely different matter: The Unix syspovconfig.h failed
to explicitly pull in <stdint.h>, and typically ended up with the
(false) conclusion that uint32_t wasn't available, resulting in
POV_UINT32, and by extension POVMS_Type, to be defined as unsigned long
(chosen as the default because that's the smallest type guaranteed by
the C++ standard to hold a 32-bit unsigned integer). In other cases
however, <stdint.h> would happen to be included before syspovconfig.h,
which then ended up with the (proper) conclusion that uint32_t was well
available, resulting in POV_UINT32, and by extension POVMS_Type, to be
defined as that type.

Obviously this brought into existence two different sets of declarations
for virtually the entire POVMS module, but only one set of definitions.

The problem hadn't surfaced earlier because POVMS_Type explicitly
defaulted to unsigned int until now.

Post a reply to this message

While I've managed to sort out the problem that surfaced on Semaphore,
something's still amiss with the current GitHub master branch: The other
automated Unix build service -- Travis CI -- keeps building binaries
that either fail with "Operation timed out." or even core dump when
trying to render the biscuits test scene. Unfortunately I can't recreate
the problem here.

Can someone please try to give me a hand in recreating and diagnosing
the problem?

Here's an outline of the system Travis CI uses for building:

Ubuntu 12.04.5 LTS "precise"
Linux 3.13.0-29-generic
autoconf 2.68
automake 1.11.3
gcc 4.6.3-1ubuntu5
ZLib 1.2.3.4
LibPNG 1.2.46
LibJPEG 80
LibTIFF 3.9.5
Boost 1.46
OpenEXR 1.6.1

The code seems to build fine on Semaphore, using the following environment:

Ubuntu 14.04 LTS v1601
autoconf 2.69
automake 1.14.1
gcc 4.8
ZLib 1.2.8
LibPNG 1.2.50
LibJPEG 80
LibTIFF 4.0.3
Boost 1.54
OpenEXR 1.6.1

Any Unix users with a bit of time to spare for helping in the
development of POV-Ray, could you please try building the current
POV-Ray master branch on your system, letting me know whether it runs ok
(please include some details on your system)? Thanks a lot!

Anyone experiencing trouble with the build and willing to go the extra
mile, please dig deeper into the matter, and let me know of your
findings. Anything that could be helpful.

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 28/01/2016 15:49, clipka a écrit :
> Are you sure that's what's happening? Because last time I checked,
> there is no problem linking two libraries into one executable even
> if they recursively call each other. And I don't think it can't get
> any more interlocked than that.

If you "link" with shared libraries, usually no problem. (but you get
other kind of problems)

But try doing that with static libraries, and the linker can be a PITA.
Well, some linkers... not all of them.

Recursive calls might be ok ( A::a calls B::b which calls again A::a,
the linker might have kept the A::a name, so all is fine. but in some
situation like A::a calls B::b which calls A::z, very first reference
of it ever, which then calls B::c, also first time,...and so on, it
can badly fails). Notice that such intricacy is usually a sign of a
design problem (easy solution: merge both libraries into a single one) )
.

Some linkers try to be smart, to reduce the size of the final binary,
so getting only the parts they really need from the static libraries.

Some other linkers are less smart: take everything, resolves name and
complains when provided more than once, leaving unresolved names up to
any system dynamic library (then execution will fails to resolve them,
but that's not the linker's problem anymore).


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlaqRMIACgkQhKAm8mTpkW3uSgP/TpH1axrUc3UXfK+l69bQ+lma
LUgGQ/pfWQkWYCItTcZYa997j0zzN/BEjEYMGSAhnZRM8Kre4sZ187VZDK+ZGPSK
OWVm0UeOc5pzDFH6LoWZp3yaf80mkpKg79TL4RtrE4Kr5Z57kKhi6rpKojBeDcNr
Nidr9RW2jDOK58ntjew=
=iBFV
-----END PGP SIGNATURE-----

Post a reply to this message

Seems to work fine here:

Ubuntu 14.04.3 LTS
autoconf 2.69
automake 1.14.1
gcc 4.8.4
ZLib 1.2.8
LibPNG 1.2.50
LibJPEG 8c
LibTIFF 4.0.3
Boost 1.54
OpenEXR 1.6.1

make check rendered the biscuits just fine.

--
jaime

Post a reply to this message

Am 28.01.2016 um 19:19 schrieb Jaime Vives Piqueres:
> Seems to work fine here:
> 
> Ubuntu 14.04.3 LTS
> autoconf 2.69
> automake 1.14.1
> gcc 4.8.4
> ZLib 1.2.8
> LibPNG 1.2.50
> LibJPEG 8c
> LibTIFF 4.0.3
> Boost 1.54
> OpenEXR 1.6.1
> 
> make check rendered the biscuits just fine.

Might actually be the exact same toolbox as on Semaphore.

Thanks for checking.

Post a reply to this message

On 01/28/2016 01:19 PM, Jaime Vives Piqueres wrote:
> Seems to work fine here:
>
> Ubuntu 14.04.3 LTS
> autoconf 2.69
> automake 1.14.1
> gcc 4.8.4
> ZLib 1.2.8
> LibPNG 1.2.50
> LibJPEG 8c
> LibTIFF 4.0.3
> Boost 1.54
> OpenEXR 1.6.1
>
> make check rendered the biscuits just fine.
>
> --
> jaime

My system is very similar and things work here too.

Ubuntu 14.04.3 LTS
Linux 3.19.0-47-generic
autoconf 2.69
automake 1.14.1
gcc 4.8.4
Boost 1.54
LibJPEG 80
LibPNG 1.2.50
LibTIFF 4.0.3
OpenEXR 1.6.1
ZLib 1.2.8

Bill P.

Post a reply to this message

Am 28.01.2016 um 16:10 schrieb clipka:

> While I've managed to sort out the problem that surfaced on Semaphore,
> something's still amiss with the current GitHub master branch: The other
> automated Unix build service -- Travis CI -- keeps building binaries
> that either fail with "Operation timed out." or even core dump when
> trying to render the biscuits test scene. Unfortunately I can't recreate
> the problem here.
> 
> Can someone please try to give me a hand in recreating and diagnosing
> the problem?
> 
> Here's an outline of the system Travis CI uses for building:
> 
> Ubuntu 12.04.5 LTS "precise"
> Linux 3.13.0-29-generic
> autoconf 2.68
> automake 1.11.3
> gcc 4.6.3-1ubuntu5
> ZLib 1.2.3.4
> LibPNG 1.2.46
> LibJPEG 80
> LibTIFF 3.9.5
> Boost 1.46
> OpenEXR 1.6.1

Okay, having gone through the (for a Windows jockey) irritating hassle
of setting up Ubuntu 12.04 myself on a VM, I can now confirm that this
is a reproducable problem with the above set-up.

But I'm a bit at a loss where to go from here; on Windows I'd just fire
up the Visual Studio IDE and interactively step through code from there.
I guess that's not how things are done on Linux, is it?

Any recommendations welcome.

Post a reply to this message