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 <dude...@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+unsubscr...@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/CAGNmyx5S6_00Y_zAh%3DSjSJKE_WRLqBc35uYCygPwhJSTFQAU_w%40mail.gmail.com.
