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

On 1/29/2016 1:58 AM, clipka wrote:

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

I do C++ on unix under eclipse. It is way primitive compared to Visual 
Studio (The C++ debugging support is primitive, java debugging support 
is comparable to VS).

Post a reply to this message

On 01/29/2016 01:58 AM, clipka wrote:
> Am 28.01.2016 um 16:10 schrieb clipka:
>
> 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.
>
I'd be tempted to try -wt1 first just to see what happens...

Not a programmer. I have done some *nix debugging on and off over the 
years. From some of those notes.

---
If you are somewhat routinely getting a core dump:

- Compile povray with the -g flag

- In the shell/xterm where you are running povray and getting a core 
file use the command(1): ulimit -c unlimited

- run povray again to get the full core file.

- Then "gdb <full_path_to_povray> core" followed by one or more of the 
following commands.
(gdb) bt
(gdb) bt full
(gdb) info threads
(gdb) thread apply all bt
(gdb) thread apply all bt full

- If the problem is in one of the libraries povray uses, you can grab 
the debug versions of those libraries, rebuild, repeat. But, I'd bail 
recommending a library update.

--- If the problem is a time out and exit, I am less sure what to do.

- You can run programs under gdb, but here my experience was many years 
ago and singular. I just don't recall. There is eclipse as mentioned, 
but I've never used it.

Bill P.

(1) - One possible gotcha here is if root on your virtual machine has 
set a low hard limit. If so, only root can increase this limit. As 
root(sudo in ubuntu) "ulimit -H unlimited".

Post a reply to this message

Am 29.01.2016 um 14:24 schrieb William F Pokorny:

> If you are somewhat routinely getting a core dump:

No, not really. "Operation timed out." is the usual deal.

Post a reply to this message

On 01/30/2016 07:16 AM, clipka wrote:
> Am 29.01.2016 um 14:24 schrieb William F Pokorny:
>
>> If you are somewhat routinely getting a core dump:
>
> No, not really. "Operation timed out." is the usual deal.
>

Just a thought, but is the "Operation timed out." message localized 
enough that you could modify the code to core dump by adding abort()?

If the time out period is really long you might be able to send an 
abort via the kill command to get a core dump. Running with 1-2 threads 
would be essential for this attempt otherwise you'd not know what 
parallel process to kill.

(And sorry to hear about that desk spill... :-) )

Bill P.

Post a reply to this message

On 1/28/2016 9:49 AM, clipka wrote:

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

Huh. I would have agreed with clipka; I thought this problem was solved 
long ago.  But I just ran into this situation with my animation 
controller.  I was refactoring my networking and the lower layer must be 
on the link line after the higher layer that calls it. It took me awhile 
to think of reordering the link line...
"What do you mean void AgentRead(SOCKET) not found?? It's been there for 
20 years!"
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)

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.

Okay, I am still officially stumped why the problem suddenly surfaced
when it did.

However, after a tedious uphill battle to first install Ubuntu 12 on an
Oracle VM, then struggling with Ubuntu's user interface to get all the
packages I thought I needed, followed by getting POV-Ray to build
without optimizations (which for some reason seemed to require an
additional boost library not required by the standard optimized build)
and with debug information, I finally got valgrind to give me some
hints. Kudos to whoever invented this piece of anti-crap.

It seems that something somehow exposed a problem with an uninitialized
data field in the POVMS message-passing layer between the back- and
front-end.

Having fixed this bug, I can now report that at last POV-Ray
successfully builds on Ubuntu 12 again.

Yay!

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

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

Mageia-5
Same problem:
g++  -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs
-Wno-non-template-friend -s -O3 -ffast-math -march=native -pthread  -L/usr/lib64
 -L/usr/lib -o povray disp_sdl.o disp_text.o ../vfe/libvfe.a
.../source/libpovray.a -lSDL -L/usr/lib64 -lSDL -lXpm  -lSM -lICE -lX11  -lIlmImf
-lIlmImf -lImath -lHalf -lIex -lIexMath -lIlmThread -lpthread  -lIlmThread
-ltiff -ljpeg -lpng -lz -lrt -lm -lboost_thread -lboost_system -lboost_thread
-lboost_date_time -pthread
.../vfe/libvfe.a(vfesession.o): In function `vfe::vfeSession::ClearOptions()':
vfesession.cpp:(.text._ZN3vfe10vfeSession12ClearOptionsEv[_ZN3vfe10vfeSession12ClearOptionsEv]+0x122):
undefined reference to `POVMSObject_New(POVMSData*, unsigned int)'

and so on...

Post a reply to this message