building hugin on fedora

[johnfi...@gmail.com]

I wanted to start this thread, even though I don't have a lot to ask/report yet, because I'll otherwise forget things, and because someone might have some useful feedback on what I have so far.

uname -a reports

Linux linux 5.15.15-200.fc35.x86_64 #1 SMP Sun Jan 16 17:37:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

I got build instructions both from

https://wiki.panotools.org/Hugin_Compiling_Fedora

and from a recent post by Bruno suggesting

sudo dnf install gcc-c++ libpano13-devel zlib-devel libtiff-devel
libjpeg-devel libpng-devel gettext-devel wxGTK3-devel boost-devel
freeglut-devel cmake desktop-file-utils OpenEXR-devel exiv2-devel
glew-devel python3-devel swig flann-devel perl-Image-ExifTool
mesa-libGLU-devel libXmu-devel sqlite-devel vigra-devel perl-podlators
fftw-devel lcms2-devel

The list of things to install is very different between those two sources.  Is that first one obsolete?

Getting everything from that first list first, it complained that wxPython doesn't exist, but I got everything else.  I didn't try cmake with just those things.

Getting Bruno's list next installed 26 packages I hadn't gotten from that first list (some things on Bruno's list that I didn't have yet, plus whatever those depended on that I didn't have).  I lost the list of what was extra, because my system crashed before I saved that list.

cmake just worked (first time that happened for me since I started trying to build hugin).  It failed for me in Windows.  It failed for me in Ubuntu (maybe because I was using an obsolete list of packages required, rather than Bruno's list).

I ran make -j16

Meanwhile I ran system monitor to see that about half my cpu capacity was in use and about 22% of ram, meaning the 16 jobs in my 16 thread cpu  were averaging half speed due to waits on disk reads.  That is as expected for this system.  It certainly means 16 is NOT too many for my hardware.

Then my system crashed.  Seemed to be a display driver crash.  Maybe there is some problem in building hugin with j16, but more likely it is a display driver bug.  In an otherwise new and powerful system, I have an ancient graphics card driving two high res displays.  The nouveau driver crashes constantly for this hardware, so I'm not using it.  I'm using the 340 driver from Nvidia, which doesn't crash much.  But it does crash.

Rebooted and built without j16

Next I need to figure out what I need to do (what else to install) to actually use what I just built.

[johnfi...@gmail.com]

I ran the hugin I built.  I did not do the LD_LIBRARY_PATH thing Bruno suggested in the other thread, because my system does have the lib64 setup (lib is 64 bit) and because ldd indicated hugin had access to all the .so files it needed without that.  I'll investigate whether something else needs that after I reboot Linux (I'm typing this on windows before rebooting a hung Linux machine).

hugin initially seemed to be working.  I loaded a project I had stitched (with poor results, but no specific malfunctions) using the Windows binary release of hugin.

Is there some problem in moving a hugin project from Windows to Fedora and/or from the released hugin build to latest (today) from mercurial?

When I stitched that, it gave the usual prompts (overwrite the previous result files, etc.) then flashed a bunch of things on screen, then hung my system (I think kdm is hung).

The log file (on a fileserver, so I can see before rebooting linux) ends with:

Blending exposure layer 0...
execvp(enblend, -f2658x5011, --compression=LZW, -o, 20220115_155306 - 20220115_155319_exposure_0000.tif, --, 20220115_155306 - 20220115_155319_exposure_layers_0000.tif) failed with error 2!

The konsole window I ran it from scrolled through lots of error messages, the still visible ones are variants on these:

(PTBatcherGUI:4786): Gtk-WARNINGS **: 10:58:16.593: for_size smaller than min_size (0 < 14) while measuring gadget (node check, owner GtkCheckButton)

(PTBatcherGUI:4786): Gtk-WARNINGS **: 10:58:16.593: Negative content height -2 (allocation 0, extents 1,1) while allocating gadget (node check, owner GtkCheckButton)

The batch processor window is up with a status of failed.  Other windows opened by the stitch action, closed right before the system hung.

[johnfi...@gmail.com]

All those warning messages distracted me from what should have been obvious:

In my Fedora system, I hadn't installed enblend

With that fixed, I seem to have things working with the hugin executable I just built.

Are all those warnings normal?  Or are they something that should be investigated?

The system hang seems to be unrelated to either those warnings or the missing enblend.  Probably more random issues with that 340 driver.  Probably I ought to buy a newer display card.

I mainly use open office calc and firefox on Fedora (I prefer to use hugin on Windows where I currently can't build it).  The nouveaux driver had problems like this all the time using just calc and firefox.  The nVidia driver never has problems in calc and firefox.  It messes up on operations like restoring after sleep.  Before starting this hugin experimentation, I never had any crashes using the 340 driver that weren't on mode changes.  So maybe something else is going on.  But likely not a hugin issue.

[Bruno Postle]

On Sat, 22 Jan 2022 at 15:39, johnfine2017 wrote:

> I got build instructions both from
> https://wiki.panotools.org/Hugin_Compiling_Fedora
> and from a recent post by Bruno suggesting

> The list of things to install is very different between those two sources. Is that first one obsolete?

The wiki will be out of date, the list of packages I gave is that used
to build the current official fedora Hugin package.

> Then my system crashed. Seemed to be a display driver crash. Maybe there is some problem in building hugin with j16, but more likely it is a display driver bug. In an otherwise new and powerful system, I have an ancient graphics card driving two high res displays. The nouveau driver crashes constantly for this hardware, so I'm not using it. I'm using the 340 driver from Nvidia, which doesn't crash much. But it does crash.

There is definitely something wrong with your graphics setup. The
standard nouveau driver might not have all the top features, but in my
experience it is very stable. You shouldn't expect a problem in Hugin
to crash the whole system like this.

All the warnings about gtk window sizes don't seem to cause any
problems here, though I have often wondered if there was something to
be gained from fixing them.

--
Bruno

[johnfi...@gmail.com]

On Saturday, January 22, 2022 at 1:27:25 PM UTC-5 bruno...@gmail.com wrote:

 The
standard nouveau driver might not have all the top features, but in my
experience it is very stable.

My experience has been very different.  Years ago at work, I was using several Centos systems with varying hardware, including different models of display card, but all display cards that used the older (now 340) driver from Nvidia.  The nouveau driver crashed a lot on any of those systems.  The Nvidia driver was rock solid.

Later using Centos at home with similar hardware, nouveau crashed a lot.  Nvidia 340 failed 100% on restore from sleep but otherwise was rock solid.  When I installed hugin, other packages upgraded, breaking firefox.  I couldn't back out changes nor could I get an updated firefox to work.  Eventually I trashed the whole install trying.  Starting over with Ubuntu, I thought Ubuntu had installed the 340 driver (I should have checked rather than trusting) so I thought I had bad ram.  I replaced everything but the graphics card and displays (graphics cards are absurdly expensive right now).  Only after Ubuntu continued to crash and then Fedora similarly crash, I finally realized all those crashes are the nouveau driver.  A Fedora forum post told me how to get past the problem in newer linux kernels of installing the ancient 340 driver.  So I switched back to that (same driver I used for years in Centos).  It sometimes recovers from sleep (never did in Centos, so in ordinary use I never enable sleep) and until this hugin activity was solid for ordinary use.

It is never easy to rule out other hardware or install issues.  But I'm pretty sure the nouveau driver never had stable support for these older architecture Nvidia cards and the Nvidia 340 driver is much better but not perfect.

Sorry I confused my video driver issues with hugin build issues.

I'd like to solve my mingw64 Windows hugin build issues and/or find out how to cross compile on Linuix for Windows.

For the moment, I don't think I have any build problems in Fedora for hugin (thanks apparently to the better dependency list you gave me).

[johnfi...@gmail.com]

On Saturday, January 22, 2022 at 10:39:36 AM UTC-5 johnfi...@gmail.com wrote:

I ran make -j16

Meanwhile I ran system monitor to see that about half my cpu capacity was in use

Then my system crashed.  Seemed to be a display driver crash.  Maybe there is some problem in building hugin with j16, but more likely it is a display driver bug.

On Saturday, January 22, 2022 at 1:27:25 PM UTC-5 bruno...@gmail.com wrote:

There is definitely something wrong with your graphics setup. The
standard nouveau driver might not have all the top features, but in my
experience it is very stable. You shouldn't expect a problem in Hugin
to crash the whole system like this.

Just wanted to mention the above crash was something that only happens with Plasma System Monitor running.  Using KSysGuard instead of  Plasma System Monitor, I get zero such problems (zero using Nvidia driver, lots of problems using nouveau driver).

So definitely nothing wrong with the hugin build (which builds even faster at -j32 than at -j16).  Maybe there is still some problem related to the ancient Nvidia card.  But I have seen symptoms of that problem only in two places: recovery from sleep (I no longer use sleep for that reason) and Plasma System Monitor (I no longer use it for that reason).

Meanwhile, I'm trying to figure out how to debug a debug build of hugin.  I still want to know why magnification to over 2**27 pixels breaks the control panel dialog and indirect evidence is pointing me into the pixmap object wrapped inside the wxBitmap object.  From the wxBitmap source code I can't even figure out what object that pixmap even is, much less look into its source code.

Long ago, I gave up trying to learn how to use gdb (but I might need to reverse that decision for this).  I'm used to debugging with CodeBlocks (which uses gdb under the hood, but hides that from me).  I knew in Windows how to get CodeBlocks to debug something that wasn't built in CodeBlocks and for this, I learned the different way to make that work in Linux.

Now CodeBlocks seems unable to understand the correspondence between binary positions and source code positions (likely because gdb is failing to do that) so it can't open the source code on break and breakpoints set in source code don't work.  The usual causes for that problem don't apply, so solutions I know in CodeBlocks from past projects, don't work.  So I'm at a dead end with CodeBlocks debugger.  Maybe there is more flexibility in gdb itself.

[Terry Duell]

On Wed, 2022-01-26 at 14:09 -0800, johnfi...@gmail.com wrote:
> On Saturday, January 22, 2022 at 10:39:36 AM UTC-5 johnfi...@gmail.com wrote:
>
> I ran make -j16
> Meanwhile I ran system monitor to see that about half my cpu capacity was in use
>
> Then my system crashed.  Seemed to be a display driver crash.  Maybe there is some
> problem in building hugin with j16, but more likely it is a display driver bug.
>
>
> On Saturday, January 22, 2022 at 1:27:25 PM UTC-5 bruno...@gmail.com wrote:
> >
> > There is definitely something wrong with your graphics setup. The
> > standard nouveau driver might not have all the top features, but in my
> > experience it is very stable. You shouldn't expect a problem in Hugin
> > to crash the whole system like this.
> >
>
>
> Just wanted to mention the above crash was something that only happens with Plasma
> System Monitor running.  Using KSysGuard instead of  Plasma System Monitor, I get
> zero such problems (zero using Nvidia driver, lots of problems using nouveau
> driver).

It's probably no real help, but just for the record I regularly build hugin rpms on
Fedora, and use the nouveau driver. I can't remember the last time I had any problems
with a build that weren't my own doing.

Cheers,
--
Terry Duell <tdu...@iinet.net.au>

[johnfi...@gmail.com]

Since I mentioned my problems with trying to start debugging a debug build of hugin, I'll describe the partial answer I've found so far.  Maybe anyone else who would try to debug hugin would already know this stuff.  But in case that is not true:

I think CodeBlocks was failing because the underlying gdb was unresponsive (haven't verified yet by retrying with CodeBlocks).

Using gdb directy, it was unresponsive after displaying a line starting with [ and ending with ] and otherwise blank.

After trying other things, I eventually realized the meaning was failure to get a response from some server that it was trying to download debug info from.

Aborting the hung gdb and restarting, it used a cache for all the debug symbols it had gotten the first time (before the failure) and got an immediate response from the server that had failed the first time and got through a bunch more before failing again.

Third time it finished downloading all those symbols.

Now I'm figuring out basics of using gdb (identifying the correct one of hugin's 36 threads to get a meaningful backtrace, setting breakpoints, looking at things).