Hard stuff for an amaturer coder here ;).
Tried putting in your libomp fix in all CMakeLists.txt in openmp-16.0.1.src
but extend path still missing. Would it be too much to ask if you uploaded
the whole repo with sources compiled included? I feel I am getting one
error after the other here ;).
openmp-13.0.1 seems to work out of the box, maybe use that?
-- LIBOMP: Library Kind -- SHARED
-- LIBOMP: Library Type -- normal
-- LIBOMP: Fortran Modules -- FALSE
-- LIBOMP: Build -- 20140926
-- LIBOMP: Use Stats-gathering -- FALSE
-- LIBOMP: Use Debugger-support -- FALSE
-- LIBOMP: Use ITT notify -- TRUE
-- LIBOMP: Use OMPT-support -- FALSE
-- LIBOMP: Use OMPD-support -- FALSE
-- LIBOMP: Use Adaptive locks -- FALSE
-- LIBOMP: Use quad precision -- FALSE
-- LIBOMP: Use Hwloc library -- FALSE
*CMake Error at runtime/src/CMakeLists.txt:11 (include): include could not
find requested file: ExtendPath*
-- Looking for sqrt in m
-- Looking for sqrt in m - found
-- Looking for __atomic_load_1
-- Looking for __atomic_load_1 - found
-- check-libomp does nothing.
-- check-ompt does nothing.
-- Found Python3:
/opt/homebrew/Frameworks/Python.framework/Versions/3.11/bin/python3.11
(found version "3.11.3") found components: Interpreter Development
Development.Module Development.Embed
-- check-openmp does nothing.
-- Configuring incomplete, errors occurred!
See also
"/Users/daniel/eoyilmaz-hugin/mac/ExternalPrograms/repository/openmp-16.0.1.src/CMakeFiles/CMakeOutput.log".
See also
"/Users/daniel/eoyilmaz-hugin/mac/ExternalPrograms/repository/openmp-16.0.1.src/CMakeFiles/CMakeError.log".
** Failed at configure step for arm **
Daniels-MacBook-Pro:~ daniel$
torsdag 27 april 2023 kl. 11:45:53 UTC+2 skrev eoyi...@gmail.com:
> This is the changes I made to ChangeUserDefinedDialog.cpp (apparently I
> included some header files that should normally be included by the
> "base_wx/platform.h"):
>
> diff -r 886e4a13e176 src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp
> --- a/src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp Sun Apr 09
> 10:11:55 2023 +0200
> +++ b/src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp Thu Apr 27
> 10:43:15 2023 +0100
> @@ -24,7 +24,9 @@
> *
> */
>
> +#include <CoreFoundation/CoreFoundation.h>
> #include "ChangeUserDefinedDialog.h"
> +#include "base_wx/platform.h"
> #include <wx/dir.h>
> #include <wx/stdpaths.h>
> #include <wx/wfstream.h>
> @@ -235,7 +237,7 @@
>
> if (thePath.IsEmpty())
> {
> wxMessageBox(_("xrc directory not found in bundle"), _("Fatal
> Error"));
> - return false;
> + return "";
> }
> return thePath + "/";
> }
>
> *Erkan Ozgur Yilmaz*
>
>
> On Thu, 27 Apr 2023 at 10:36, dudek53 <dud...@gmail.com> wrote:
>
>> I´ll look into this later today or as soon as possible. i had no issues
>> around gettext though but I´ll test exactly as you descripe.
>>
>> Could you print the exact fix for this. Tested what you described but if
>> still fails:
>> Ah yeah sorry I didn’t mention that, I did introduce a couple of changes
>> to the external libraries, I’m not in front of my computer but what I
>> remember is that I changed this line:
>>
>>
>> */Users/daniel/hugin/src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp:238:20:
>>
>> error: calling a private constructor of class 'wxString' return
>> false;*
>>
>> To return “” instead, and there were other changes in gettext and in
>> glib2 as I remember, will post them in a minute when I got back home.
>>
>> torsdag 27 april 2023 kl. 11:20:32 UTC+2 skrev eoyi...@gmail.com:
>>
>>> So it seems that I updated libomp and gettext:
>>>
>>> *libomp*
>>> CMake ExtendPath missing
>>> add the following code in CMakeLists.txt
>>>
>>> function(extend_path joined_path base_path current_segment)
>>> if("${current_segment}" STREQUAL "")
>>> set(temp_path "${base_path}")
>>> elseif("${base_path}" STREQUAL "")
>>> set(temp_path "${current_segment}")
>>> elseif(IS_ABSOLUTE "${current_segment}")
>>> message(WARNING "Since \"${current_segment}\" is absolute, it overrides
>>> base path: \"${base_path}\".")
>>> set(temp_path "${current_segment}")
>>> else()
>>> set(temp_path "${base_path}/${current_segment}")
>>> endif()
>>> set(${joined_path} "${temp_path}" PARENT_SCOPE)
>>> endfunction()
>>>
>>> *gettext*
>>>
>>> Replace :
>>> static _Noreturn__ void
>>> print_and_abort (void)
>>>
>>> With:
>>> static __attribute_noreturn__ void
>>> print_and_abort (void)
>>>
>>> on all the files it exists
>>>
>>> On Thursday, 27 April 2023 at 09:30:59 UTC+1 dud...@gmail.com wrote:
>>>
>>>> Nice. Do post. Seems we can soon deliver a solid apple silicon hugin
>>>> version compiler :).
>>>>
>>>> torsdag 27 april 2023 kl. 09:57:22 UTC+2 skrev eoyi...@gmail.com:
>>>>
>>>>> Ah yeah sorry I didn’t mention that, I did introduce a couple of
>>>>> changes to the external libraries, I’m not in front of my computer but
>>>>> what
>>>>> I remember is that I changed this line:
>>>>>
>>>>>
>>>>> */Users/daniel/hugin/src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp:238:20:
>>>>>
>>>>> error: calling a private constructor of class 'wxString'
>>>>> return
>>>>> false;*
>>>>>
>>>>> To return “” instead, and there were other changes in gettext and in
>>>>> glib2 as I remember, will post them in a minute when I got back home.
>>>>>
>>>>> On Thu, 27 Apr 2023 at 08:30, dudek53 <dud...@gmail.com> wrote:
>>>>>
>>>>>> Error seems related to make package bundle which I did not test yet
>>>>>> so I guess this needs fixing:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *#elif defined __WXMAC__ && defined MAC_SELF_CONTAINED_BUNDLE //
>>>>>> initialize paths { wxString thePath =
>>>>>> MacGetPathToBundledResourceFile(CFSTR("xrc")); if
>>>>>> (thePath.IsEmpty()) { wxMessageBox(_("xrc directory
>>>>>> not
>>>>>> found in bundle"), _("Fatal Error")); return false; }
>>>>>>
>>>>>> return thePath + "/"; }*
>>>>>>
>>>>>> torsdag 27 april 2023 kl. 09:26:42 UTC+2 skrev dudek53:
>>>>>>
>>>>>>> Hello Erkan. Tested your uploaded hugin source and most of it works
>>>>>>> out of the box.
>>>>>>> The script libglib2.sh in scripts folder tries this in the beginning:
>>>>>>> *./configure ] && ./autogen.sh*
>>>>>>> There is no ./autogen.sh in later versions so one could do:
>>>>>>> *meson _build*
>>>>>>> Instead accrording to glib2 install notes.
>>>>>>>
>>>>>>> I do configure and then make and all binaries are created but I fail
>>>>>>> here. I will try adding your libfile to see if this will help but do
>>>>>>> you
>>>>>>> see the issue maybe?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> */Users/daniel/hugin/mac/ExternalPrograms/repository/include/wx-3.1/wx/osx/app.h:125:26:
>>>>>>>
>>>>>>> note: overridden virtual function is here virtual void
>>>>>>> MacOpenFiles(const wxArrayString &fileNames) ;
>>>>>>> ^3
>>>>>>> warnings generated.[ 89%] Building CXX object
>>>>>>> src/hugin1/ptbatcher/CMakeFiles/PTBatcherGUI.dir/ProgressStatusBar.cpp.o[
>>>>>>>
>>>>>>> 90%] Building CXX object
>>>>>>> src/hugin1/ptbatcher/CMakeFiles/PTBatcherGUI.dir/ChangeUserDefinedDialog.cpp.o/Users/daniel/hugin/src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp:234:60:
>>>>>>>
>>>>>>> error: use of undeclared identifier 'CFSTR' wxString thePath =
>>>>>>> MacGetPathToBundledResourceFile(CFSTR("xrc"));
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ^/Users/daniel/hugin/src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp:238:20:
>>>>>>>
>>>>>>> error: calling a private constructor of class 'wxString'
>>>>>>> return
>>>>>>> false;
>>>>>>>
>>>>>>> ^/Users/daniel/hugin/mac/ExternalPrograms/repository/include/wx-3.1/wx/string.h:324:3:
>>>>>>>
>>>>>>> note: declared private here wxString(int); ^2 errors
>>>>>>> generated.make[2]:
>>>>>>> ***
>>>>>>> [src/hugin1/ptbatcher/CMakeFiles/PTBatcherGUI.dir/ChangeUserDefinedDialog.cpp.o]
>>>>>>>
>>>>>>> Error 1make[1]: ***
>>>>>>> [src/hugin1/ptbatcher/CMakeFiles/PTBatcherGUI.dir/all]
>>>>>>> Error 2make: *** [all] Error 2Daniels-MacBook-Pro:build daniel$ *
>>>>>>>
>>>>>>>
>>>>>>> onsdag 26 april 2023 kl. 22:56:45 UTC+2 skrev dudek53:
>>>>>>>
>>>>>>>> Nicely done. march=native and correcting paths and such, and I see
>>>>>>>> you did a good job here. Unfortunately I started by reading some mac
>>>>>>>> wiki
>>>>>>>> link suggesting using port for installation but brew seems more stable.
>>>>>>>> Maybe I´ll dive in again soon to see If I finally will get my M1
>>>>>>>> doing a full compilation finally :).
>>>>>>>>
>>>>>>>> On Wed, Apr 26, 2023 at 9:22 PM Erkan Özgür Yılmaz <
>>>>>>>> eoyi...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Pushed my changes to my repository:
>>>>>>>>>
>>>>>>>>> https://sourceforge.net/u/eoyilmaz/hugin/ci/default/tree/
>>>>>>>>>
>>>>>>>>> Because I changed the build scripts so that they are only good for
>>>>>>>>> building arm64 I'm not sure if I should create a PR yet. During my
>>>>>>>>> research
>>>>>>>>> I saw examples of building universal binaries but I didn't bother
>>>>>>>>> doing
>>>>>>>>> that.
>>>>>>>>>
>>>>>>>>> *Erkan Ozgur Yilmaz*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, 26 Apr 2023 at 09:07, dudek53 <dud...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Run xattr -cr in terminal on the whole app and it will run.
>>>>>>>>>>
>>>>>>>>>> onsdag 26 april 2023 kl. 09:50:39 UTC+2 skrev mikko....@kavi.fi:
>>>>>>>>>>
>>>>>>>>>>> It’s cool to have a 2022 M1 build, finally. But macOS says the
>>>>>>>>>>> application is damaged, and wont run it.
>>>>>>>>>>>
>>>>>>>>>>> On Wednesday, April 26, 2023 at 6:02:51 AM UTC+3
>>>>>>>>>>> dud...@gmail.com wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Cool. I had similar issues, also missing the
>>>>>>>>>>>> libboost_atomic.dylib. *PackageMacAppBundleLibs.sh *gave up
>>>>>>>>>>>> after a while as it needs to get a lot of fixes.
>>>>>>>>>>>> Anyway. Would be great if scripts could be updated and shared
>>>>>>>>>>>> for M1.
>>>>>>>>>>>> An d I see your build still gives corrupt output from using
>>>>>>>>>>>> --gpu with align_image_stack :).
>>>>>>>>>>>>
>>>>>>>>>>>> *M1* natively (*aarch64/arm64*)? Are you compiling with
>>>>>>>>>>>> aarch64? Could you share your scripts maybe?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> onsdag 26 april 2023 kl. 00:39:20 UTC+2 skrev eoyi...@gmail.com
>>>>>>>>>>>> :
>>>>>>>>>>>>
>>>>>>>>>>>>> Hey, after working on it for the last 1.5 week, finally I was
>>>>>>>>>>>>> able to build and run *Hugin 2022.1.0* on my *M1* natively (
>>>>>>>>>>>>> *aarch64/arm64*). But, *nona* is still failing to merge my
>>>>>>>>>>>>> *OpenEXR*'s in some cases.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I had to use:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - boost 1.81.0
>>>>>>>>>>>>> - exiv2-0.27.6
>>>>>>>>>>>>> - gettext-0.21.1
>>>>>>>>>>>>> - glib-2.76.1
>>>>>>>>>>>>> - openexr-v2.5.8 (as I understand 3.1.7 has breaking
>>>>>>>>>>>>> changes)
>>>>>>>>>>>>> - libffi-3.4.3
>>>>>>>>>>>>> - openmp-16.0.1
>>>>>>>>>>>>>
>>>>>>>>>>>>> and had to update nearly all the build scripts under
>>>>>>>>>>>>> *mac/ExternalPrograms/scripts*, also somehow the
>>>>>>>>>>>>> *libboost_atomic.dylib* is not getting included by the
>>>>>>>>>>>>> packaging script, I had to update the
>>>>>>>>>>>>> *PackageMacAppBundleLibs.sh* to copy it manually for each app.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'll keep working on it, if anyone wants to try it you can
>>>>>>>>>>>>> download it from this link:
>>>>>>>>>>>>> https://www.dropbox.com/sh/u1t2thzv3bb45xn/AAB16jItGM8ZkumJg8eXPsL5a?dl=0
>>>>>>>>>>>>>
>>>>>>>>>>>>> One more thing, I also included *"libboost_atomic.dylib"*,
>>>>>>>>>>>>> put it in to *"/usr/local/lib/"*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Erkan Ozgur Yilmaz
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sunday, 9 April 2023 at 15:41:42 UTC+1 dud...@gmail.com
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi!
>>>>>>>>>>>>>> Yes, its says ping pong rendering, not familiar with this
>>>>>>>>>>>>>> concept.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I changed the numbers and it works so far. It´s nothing I
>>>>>>>>>>>>>> would assume would be used in main source. My contribution here
>>>>>>>>>>>>>> is of open
>>>>>>>>>>>>>> source value for anybody getting similar issues or for the code
>>>>>>>>>>>>>> author or
>>>>>>>>>>>>>> anyone else interested in this to look into changing or refine
>>>>>>>>>>>>>> code. Maybe
>>>>>>>>>>>>>> even I will have a deeper look, idk. Questions are valid though.
>>>>>>>>>>>>>> Is the
>>>>>>>>>>>>>> code doing more harm than good etc. Both original and my blind
>>>>>>>>>>>>>> fix.
>>>>>>>>>>>>>> By the way. A few places with "fixme" in
>>>>>>>>>>>>>> *ImageTransformsGPU.cpp* and where the coder simply
>>>>>>>>>>>>>> commented out code after testing for speed reason not really
>>>>>>>>>>>>>> knowing the
>>>>>>>>>>>>>> cause of the behaviour so I am not completely alone in the world
>>>>>>>>>>>>>> accepting
>>>>>>>>>>>>>> irregularities here :).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Seems I have arrived quite late to hugin party and I am
>>>>>>>>>>>>>> grateful that I at least could get some sort of contact with you
>>>>>>>>>>>>>> and Max.
>>>>>>>>>>>>>> Really nice program and the enfuse/align has meant a lot to a
>>>>>>>>>>>>>> lot of
>>>>>>>>>>>>>> photographers out there. Really cool stuff.
>>>>>>>>>>>>>> /Daniel
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> söndag 9 april 2023 kl. 16:05:24 UTC+2 skrev T. Modes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> dud...@gmail.com schrieb am Sonntag, 9. April 2023 um
>>>>>>>>>>>>>>> 11:16:36 UTC+2:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi. Are these numbers applied also to at/nvidia cards or do
>>>>>>>>>>>>>>> they apply only for other cards not defined? If applied
>>>>>>>>>>>>>>> globally tests show
>>>>>>>>>>>>>>> no benefit having larger dest chunks like 16 + 16 + 8.
>>>>>>>>>>>>>>> More testes shows too high negative numbers will hang
>>>>>>>>>>>>>>> processing, while too high, as we know corrupts framebuffering.
>>>>>>>>>>>>>>> Question remains. Could code be made more robust removing or
>>>>>>>>>>>>>>> changing behaviour in this particular place?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You can't simply change randomly numbers and hope that this
>>>>>>>>>>>>>>> fixes it. The meaning of the number is written directly above
>>>>>>>>>>>>>>> the line in
>>>>>>>>>>>>>>> the comment.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> By the way. What is the real cause of the issue here?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I assume that it reads only the first dest chunk correctly
>>>>>>>>>>>>>>> back. The second and further one are not correctly read back.
>>>>>>>>>>>>>>> But I don't
>>>>>>>>>>>>>>> know why it works on most systems except the M1 one. Apple must
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> something special in its implementation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>> 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 on the web visit
>>>>>>>>>> https://groups.google.com/d/msgid/hugin-ptx/bf842aab-99a2-4e80-a7d6-86707ca881ecn%40googlegroups.com
>>>>>>>>>>
>>>>>>>>>> <https://groups.google.com/d/msgid/hugin-ptx/bf842aab-99a2-4e80-a7d6-86707ca881ecn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>>>> .
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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 on the web visit
>>>>>>>>> https://groups.google.com/d/msgid/hugin-ptx/CAGNmyx4hAh59gMArYiSaeLnh2Fo-0p6P2SL3WYSubuwTmR7ewA%40mail.gmail.com
>>>>>>>>>
>>>>>>>>> <https://groups.google.com/d/msgid/hugin-ptx/CAGNmyx4hAh59gMArYiSaeLnh2Fo-0p6P2SL3WYSubuwTmR7ewA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>> --
>>>>>> 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 on the web visit
>>>>>> https://groups.google.com/d/msgid/hugin-ptx/236fd51f-29e6-41f5-845c-3491be0b4f1fn%40googlegroups.com
>>>>>>
>>>>>> <https://groups.google.com/d/msgid/hugin-ptx/236fd51f-29e6-41f5-845c-3491be0b4f1fn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>> --
>>>>> Erkan Ozgur Yilmaz
>>>>>
>>>> --
>> 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 on the web visit
>> https://groups.google.com/d/msgid/hugin-ptx/c3ce4884-a496-468e-a044-35799281718bn%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/hugin-ptx/c3ce4884-a496-468e-a044-35799281718bn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/6db64d0f-6a65-444f-ab4c-bb646062c526n%40googlegroups.com.
