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

Reply via email to