On 2/9/25 09:52, Bald Eagle wrote:

Hi,

First - first, thanks for attempting to build the new yuqk fork release.

---

First, I think what jr suggested about missing headers is a probable 
cause. IIRC (probably not), someone else was missing usual x-windows 
libraries too somewhat recently, on trying to build and saw a similar issue.

Except my 'first' reaction is how did this invalid build state slip past 
the x-windows configure (autotools) code...

Do you still have your config.log file? Near the bottom do you see the 
lines:

#define HAVE_LIBSDL2 1

#define BUILTIN_XWIN_DISPLAY "enabled"

Have you otherwise sorted out the cause yourself?

I'm, vaguely aware the underlying x-windows (Xorg) system is slowly 
being changed to something called Wayland. When I next can, I'll spend 
some time digging around. Last I knew there were no linux distributions 
shipped with Wayland as the default (user have to switch to do it 
themselves), but maybe that has changed and with it something about the 
'effective' windowing build support with linux distributions.

As a near term fix, you can install the sdl2 development libraries (if 
you have not) and it should be if you can use '--without-x' when you 
configure and build with the SDL2 preview window support instead. The 
yuqk default is to build and run with X windows, but it will always 
enable the newest SDL* windowing library too as part of the build, if it 
is available (and the user hasn't set a configuration option to disable it).

You can also build and run with no preview window capability at all by 
disabling both X and SDL previews.

> So, I noticed in the installation instructions there is the command:
> 
> ../configure -q COMPILED_BY="name" CXXFLAGS="-O2" --prefix=/tmp/yuqk_427af17e
> 
> when in fact the package I was trying to compile/install was
> povray-3.8.0-x.yuqk_a5c25dda
> 

Yeah, that's a bit confusing. Let me go clean it up for the next 
release. Ah, it's pervasive. I'll put it on the list to add something to 
yuqk's 'make dist' process to update it to the current commit string for 
each release.

> Once yuqk gets installed, I guess the program is still called povray, since the
> make check runs the following:
> 
> ../unix/povray +i./scenes/biscuit.pov -f +d -p +v +w320 +h240 +a0.3 +L./include
> 
> I'm guessing that for routine rendering, I can use alias to make something like
> "yuqk biscuit.pov"
> use the full path to yuqk povray and &1 to render whatever .pov file I throw at
> it.
> 

The expectation is that yuqk's 'povray' executable will be run using a 
wrapper script. There is an example script in the root directory of the 
unpacked source code called 'yuqk'. The internals of which are updated 
to point to your install location for the release prior to copying the 
script to you $HOME/bin directory, for example. You can also update that 
'yuqk' script in place as a way to quickly run without doing a 'make 
install'.

(Yep, I see too this another place where I should automatically update 
to the current release's commit string)

The yuqk fork is changing significantly release to release. The 
expectation is those using the yuqk fork will end up having many yuqk 
scripts in there $HOME/bin directory each pointing to a small install 
location of about 5MB.

I myself have: yuqk_3317dfc0, yuqk_9871ed6e and yuqk_a5c25dda wrapping 
builds / installs of the last three yuqk fork releases. I also have 
several development wrapper scripts pointing to different build 
configurations of development code at any given time (Something 
autotools supports well) - FWIW.

I hope my rambling of some help.

Bill P.

Post a reply to this message