Build issues for Hugin on macOS (Apple Silicon)

[Guillaume Didier]

Good morning / afternoon.

I’ve been investigating how to build hugin properly for Apple Silicon (and if I manage to iron out the bugs), I’d be willing to help maintain a build for the recent OS.

I’ve found a few issues, which I was able to fix, mostly by updating to newer library versions.

The levmar code has an issue identical to https://github.com/astromatic/psfex/issues/12, which I fixed using the same fix as https://github.com/astromatic/psfex/commit/f096d495c7e1f21dedbd40b207935f500850a88e

However, the following code, in hugin-2025.0.0/src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp, seems to be wrong and cannot compile on macOS.

/** return path to data directory, it depends on operating system */

wxString GetDataPath()

{

#if defined __WXMSW__

    wxFileName exePath(wxStandardPaths::Get().GetExecutablePath());

    exePath.RemoveLastDir();

    const wxString huginRoot = exePath.GetPath(wxPATH_GET_VOLUME | wxPATH_GET_SEPARATOR);

    return huginRoot + "share\\hugin\\data\\";

#elif defined __WXMAC__ && defined MAC_SELF_CONTAINED_BUNDLE

    // initialize paths

    {

        wxString thePath = MacGetPathToBundledResourceFile(CFSTR("xrc"));

        if (thePath.IsEmpty())

        {

            hugin_utils::HuginMessageBox(_("xrc directory not found in bundle"), _("PTBatcherGUI"), wxOK|wxICON_ERROR, this);

            return wxEmptyString;

        }

        return thePath + "/";

    }

#elif defined UNIX_SELF_CONTAINED_BUNDLE

    // initialize paths

    {

        wxFileName exePath(wxStandardPaths::Get().GetExecutablePath());

        exePath.RemoveLastDir();

        const wxString huginRoot = exePath.GetPath(wxPATH_GET_VOLUME | wxPATH_GET_SEPARATOR);

        return huginRoot + "share/hugin/data/";

    }

#else

    // add the locale directory specified during configure

    return INSTALL_DATA_DIR;

#endif

}

Under defined __WXMAC__ && defined MAC_SELF_CONTAINED_BUNDLE, this results in attempting to compile the line

hugin_utils::HuginMessageBox(_("xrc directory not found in bundle"), _("PTBatcherGUI"), wxOK|wxICON_ERROR, this);

while being outside of a class method.

This looks like a refactor issue using a non method helper.

Since I’m more a git than a hg person, I haven’t gotten around figuring out when that issue was introduced though.

Anyone more familiar can comment on this, and what should the proper fix be ?

(More generally, is it the case that macOS builds have not been tested at all for a while?)

Guillaume DIDIER

[T. Modes]

Hi Guillaume,

Guillaume DIDIER schrieb am Mittwoch, 19. November 2025 um 10:21:20 UTC+1:

I’ve been investigating how to build hugin properly for Apple Silicon (and if I manage to iron out the bugs), I’d be willing to help maintain a build for the recent OS.

nice, that somebody steps in.

 

I’ve found a few issues, which I was able to fix, mostly by updating to newer library versions.

The levmar code has an issue identical to https://github.com/astromatic/psfex/issues/12, which I fixed using the same fix as https://github.com/astromatic/psfex/commit/f096d495c7e1f21dedbd40b207935f500850a88e

This is now fixed in repository, default branch. Thanks for the link.

However, the following code, in hugin-2025.0.0/src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp, seems to be wrong and cannot compile on macOS.

<snip>

Under defined __WXMAC__ && defined MAC_SELF_CONTAINED_BUNDLE, this results in attempting to compile the line

hugin_utils::HuginMessageBox(_("xrc directory not found in bundle"), _("PTBatcherGUI"), wxOK|wxICON_ERROR, this);

while being outside of a class method.

This looks like a refactor issue using a non method helper.

This can be fixed by replaceing this with wxGetActiveWindow()

I committed the changes to the default branch. 

 

Since I’m more a git than a hg person, I haven’t gotten around figuring out when that issue was introduced though.

hg blame could help here. Or I use the GUI TortoiseHg.

(More generally, is it the case that macOS builds have not been tested at all for a while?)

Yes. Nobody stepped in. There may be other issues on Mac hang around.

Thomas

[Guillaume Didier]

Hello,

I have a good news and a bad news.

The good news is that I have successfully compiled a Hugin.app standalone bundle for Apple Silicon macOS Tahoe & Sequoia.

The bad news is that it crashes immediately, and there may be several bugs to fix.

The first one is that in MainFrame::MainFrame, the call to GetDPIScaleFactor() triggers a null pointer dereference in wxWindow::GetContentScaleFactor (/wxWidgets-3.3.1/src/osx/window_osx.cpp:1188).

(This could either be caused by wxWindowMac::GetPeer (window_osx.cpp:278 in wxWidgets-3.3.1) returning nullptr, OR an issue in wxWidgetCocoaImpl::GetContentScaleFactor (wxWidgets-3.3.1/src/osx/cocoa/window.mm:2840)

(I may attempt to rebuild using wxWidget 3.2 at some point during the weekend, but I suspect this might be a chicken and egg issue (you can’t get the DPI Scale Factor until you have a window already open, since not all screen in the system may have the same scale factor, this code has been in wxWidgets for 5 years.

Once I replace this call with returning the 1.5 DPI scale factor that Retina display is supposed to use, I get the splash screen to appear, but get an error message about missing SVG assets. (The 1.5 factor might be wrong though).

I am not sure whether this is a wxWidgets or a Hugin bug in the end.

(Should we move this discussion off list, to avoid spamming everyone here ?)

Guillaume DIDIER

So, I sorted a large amount of nonsense due to clang++ picking up the wrong headers, and one wxWidgets incompatible change, now I just need to hunt down some library that are being picked up from homebrew (either change the configure options to disable or use built-in versions, or add them as Extra dependencies).

But it looks like I’ll soon have a build on Apple Silicon, macOS Tahoe.

Is there a checklist to ensure the software runs properly ?

Guillaume DIDIER

Le 19 nov. 2025 à 11:22, 'T. Modes' via hugin and other free panoramic software <hugi...@googlegroups.com> a écrit :



--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hugin-ptx/3aca0192-d1f8-439f-b033-d9015c619d8bn%40googlegroups.com.

[dudek53]

Nice to see progress on mac end. I will,.when I have time, try and help. Been compiling for arm64 before this recent code base. A lot of things needed. Even when successfully compiled codesigning removal is one thing to fix among other things.

Just keep at it. Eventually you'll get there.

To view this discussion visit https://groups.google.com/d/msgid/hugin-ptx/2539896E-3614-4AC9-B2A5-66D38A679A8B%40outlook.fr.

[Guillaume Didier]

@Dudek53,

Would you mind telling what was your last successful build (hugin source version, mac OS target, and versions of dependency used. Is this a standalone bundle, or relying on e.g. home-brew for dependencies).

As for code signing and notarisation, I used to have a Apple Developer account, I could perhaps reactivate it to get cleanly signed Bundles, if all other issues get resolved.

Guillaume

To view this discussion visit https://groups.google.com/d/msgid/hugin-ptx/CAHk3tqidRAh_HcpFWArkLHFRfxte6ZHVEN2z2yRxQhTRkVPSCQ%40mail.gmail.com.

[dudek53]

Check latest answers in this thread.

https://groups.google.com/g/hugin-ptx/c/cAzcl7HaQs4/m/DhteVyvBAQAJ?utm_medium=email&utm_source=footer

I've built successfully forrecwnt two years or so.

[dudek53]

Also repo here.

https://bitbucket.org/Dannephoto/hugin/src/master/

[T. Modes]

Hi Guillaume,

Guillaume DIDIER schrieb am Freitag, 21. November 2025 um 10:56:16 UTC+1:

The good news is that I have successfully compiled a Hugin.app standalone bundle for Apple Silicon macOS Tahoe & Sequoia.

Good to hear. 

The first one is that in MainFrame::MainFrame, the call to GetDPIScaleFactor() triggers a null pointer dereference in wxWindow::GetContentScaleFactor (/wxWidgets-3.3.1/src/osx/window_osx.cpp:1188).

(This could either be caused by wxWindowMac::GetPeer (window_osx.cpp:278 in wxWidgets-3.3.1) returning nullptr, OR an issue in wxWidgetCocoaImpl::GetContentScaleFactor (wxWidgets-3.3.1/src/osx/cocoa/window.mm:2840)

With your description I tried to fix it. Please test if the attached patch fixes the issue.

 

Once I replace this call with returning the 1.5 DPI scale factor that Retina display is supposed to use, I get the splash screen to appear, but get an error message about missing SVG assets. (The 1.5 factor might be wrong though).

The svg files should be installed from src/hugin1/hugin/xrc/data/CMakeLists.txt, lines 2 and 3 

Is there a filename mentioned? Which svg files is missing?

Thomas

[Guillaume Didier]

This indeed fixes the nullptr issue.

Here is the next issue.

The missing data files are all SVG files, and are not found in the bundle (I see no SVG files in it).

(I do not see a single SVG file in the build tree, perhaps the bundle build process, by passes install and copy stuff separately, or this is done 

(Amusing note, the generate DMG still contains some CMakeLists.txt files ^^’)

I haven’t managed to figure out why these SVG files weren’t getting copied.

I the meantime adding them manually to Hugin.app and PTBatcher.app got hugin to work.

(Attached a rather stupid pano which I used as an example)

Guillaume

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/hugin-ptx/dfeba1db-1873-4ca2-a58a-55edc3cec28dn%40googlegroups.com.
<fix_dpiscale_MacOS.diff>

[T. Modes]

Hi Guillaume,

Guillaume DIDIER schrieb am Freitag, 21. November 2025 um 19:18:08 UTC+1:

This indeed fixes the nullptr issue.

Ok. I committed then the changes to default branch. 

Here is the next issue.

The missing data files are all SVG files, and are not found in the bundle (I see no SVG files in it).

(I do not see a single SVG file in the build tree, perhaps the bundle build process, by passes install and copy stuff separately, or this is done 

I think I found the missing part (see changeset 6dcb654aa654). I added the svg files to the list which should be copied to the bundle. I hope this fixes the issue. Otherwise it should give you a hint where to look

Thomas

[Guillaume Didier]

As an additionnel goody, I got OpenMP to work.

(There’s just a deprecation warning triggered in enabled-enfuse.

OMP: Info #276: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead.

Have we got any effective way of communicating with enabled-enfuse to see if that can be fixed ?

I confirm the build is fixed and Hugin now runs properly.

I’ll see tomorrow if I can clean up my patches (there’s one wxWidget change I’ve dealt with myself, the massive dependency upgrade which should definitely be reviewed, and then the OpenMP stuff still need some work, since it currently uses a ugly hack : (I replaced my brew-LLVM's libomp with a symlink to the one built for the correct Deployment Target, but that’s not a good idea).

(Note, I’m a git person, not a hg one, so I could use some non-null pointers on how to properly send you my work for upstreaming).

dudek53 also has a few more stuff on his side which should probably be reviewed too.

(The Nona GPU thing for instance).

Guillaume

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/hugin-ptx/e3aa43a2-a008-470b-86f2-bb62f14837e1n%40googlegroups.com.

[Guillaume Didier]

That possibly unstable build can be obtained at https://vrac.sobex.net/Hugin-2025.1.0.dmg

It’s sha512sum is 

7325416f700b7955f73486b65030a3a604c2507c0fce617b5e5951dd1ce1f73f74f7439c245c8ff4e143e02926a4b0b7d8b7d33abb840678192a2f4466c24d51  Hugin-2025.1.0.dmg

If anyone wants to test it (and find more bugs). @dudek53 I assume you may have some ideas of the stuff you patched, if things still blow up, it would be interesting to know, so we can get these fixes.

Guillaume

To view this discussion visit https://groups.google.com/d/msgid/hugin-ptx/4E9F7815-0D50-4856-8B8F-DAB0D46CE782%40outlook.fr.

[dudek53]

Impressive. Works. At least opens up and I can add images. Unfortunately I never use hugin personally, only enfuse and align_image_stack but even to get the program opened and chewing files indicates stellar progress. Tested on Macbook Pro M4 Sequoia 15.5.

as usual in terminal to bypass gatekeeper.

xattr -cr drag/hugin/folder/here

enter.

[Guillaume Didier]

@Tomas

One of the fixes I had to do to get things to compile is remove the return false; at src/hugin1/stitch_project/hugin_stitch_project.cpp:126, since this is not a compatible type with a constructor return type.

I’m not sure what the appropriate behaviour is (return; nothing, or abort).

I have two other patches to the source code which I am confident in, and then I’ll have the dependency update.

Guillaume

[T. Modes]

Hi Guillame,

Guillaume DIDIER schrieb am Freitag, 21. November 2025 um 23:32:44 UTC+1:

One of the fixes I had to do to get things to compile is remove the return false; at src/hugin1/stitch_project/hugin_stitch_project.cpp:126, since this is not a compatible type with a constructor return type.

I’m not sure what the appropriate behaviour is (return; nothing, or abort).

Thanks, fixed in repository.

 

I have two other patches to the source code which I am confident in, and then I’ll have the dependency update.

The best way is to create a diff file/patch with hg diff. (this should be similar to git diff)

If possible split the patch into parts if the changes that are independ on each other. (e.g. source code changes and changes to build scripts).

Thomas

[Guillaume Didier]

Hi Tomas,

Here are the first two patches of the series, which concern the source code.

The build script changes are a bit more involved and require a bit more cleanup.

(I also want to add a checksum check on the source tarballs)

From a changeling perspective, should I increment the patch version in CMakeLists.txt and refer to this version when updating the file documentations ?

Guillaume

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/hugin-ptx/92cfb860-7520-4b57-9f4b-d0b8767b35fcn%40googlegroups.com.

[T. Modes]

Hi Guillaume,

Guillaume DIDIER schrieb am Samstag, 22. November 2025 um 09:50:03 UTC+1:

Here are the first two patches of the series, which concern the source code.

thanks again. One I had to rework otherwise it broke compilation on my machine.

The second one I commited. 

From a changeling perspective, should I increment the patch version in CMakeLists.txt and refer to this version when updating the file documentations ?

Odd-numberd minor versions are considers development versions. For these the patch level is not used, instead the changeset hash is added to the version.

Only for even-numbered minor versions the patch number can be used.

Changes to the version should be done in separate changesets to make it easier to transplant the changes (cherrypick in git speech) between the branches.

So at the current state this should not be necessary.

Thomas