Question about new Craft issue

Robert Lancaster rlancaste at gmail.com
Sun Jan 29 02:36:52 GMT 2023


Just a little update, I found that if I changed the build type to “Release” instead of “RelWithDebInfo” it completes with no error.  So that means two things.  We can release KStars this time with no issues I hope.  But also, I have narrowed down the problem, it is definitely somehow related to dsymutil, architecture, and debug symbols.  So it is not as urgent, but anybody got any ideas?

> On Jan 27, 2023, at 11:11 PM, Robert Lancaster <rlancaste at gmail.com> wrote:
> 
> Hey guys,  I recently sent this message to Hannah von Reth in case it is caused by Craft.  I don’t know what is actually causing the problem.  I was wondering if anyone has any insight about what could be the cause.
> 
> Thanks,
> 
> Rob
> 
>> Begin forwarded message:
>> 
>> From: Robert Lancaster <rlancaste at gmail.com>
>> Subject: Question about new Craft issue
>> Date: January 27, 2023 at 11:09:03 PM EST
>> To: Hannah von Reth <vonreth at kde.org>
>> Cc: Jasem Mutlaq <mutlaqja at ikarustech.com>
>> 
>> Hi Hannah,
>> 
>> An issue happened a month or two ago with one of our 3rd Party Drivers in KStars/INDI and it prevented the build from finishing.  I suspect it was some change in Craft, but I am not sure.  I googled the problem, but I could not easily figure out what was wrong. We needed to get KStars released, so we disabled that particular driver from the build until we figured out the issue.  I haven’t figured it out yet.   The problem is that it has now happened to another driver.  I will try to explain the behavior here.  Please let me know if you have any insight, know that something changed in craft, or know who I can contact.  I suppose we could disable another driver, but I would prefer to address the issue because I do not think this is actually an issue with the driver itself and every time we do that, we are preventing KStars users with certain equipment from using KStars, not to mention the fact that the hard work of whoever developed each driver would not get included in the final version for no good reason.
>> 
>> The issue arises when all the driver libraries have finished building and they are in the process of getting installed.  Craft is running various commands including install_name_tool, dsymutil, strip, and codesign to finalize the installation.   When it gets to the driver in question, it tries to run the commands and somehow it fails to find a target.  This happens on both my own computer and on the craft server.  It never happened before a couple of months ago.  Below is an example of the issue.  First I have a library that appeared to complete the commands successfully.  Then the current one with the issue:
>> 
>> 
>> executing command: /Users/rlancaste/AstroRoot/craft-root/bin/dsymutil /Users/rlancaste/AstroRoot/craft-root/build/libs/indiserver-3rdparty-libraries/image-RelWithDebInfo-master/lib/libnncam.1.49.1.dylib -o /Users/rlancaste/AstroRoot/craft-root/build/libs/indiserver-3rdparty-libraries/image-RelWithDebInfo-master-dbg/lib/libnncam.1.49.1.dylib.dSYM
>> warning: no debug symbols in executable (-arch x86_64)
>> warning: no debug symbols in executable (-arch i386)
>> executing command: /usr/bin/strip -x -S /Users/rlancaste/AstroRoot/craft-root/build/libs/indiserver-3rdparty-libraries/image-RelWithDebInfo-master/lib/libnncam.1.49.1.dylib
>> executing command: /usr/bin/codesign -f -s - /Users/rlancaste/AstroRoot/craft-root/build/libs/indiserver-3rdparty-libraries/image-RelWithDebInfo-master/lib/libnncam.1.49.1.dylib
>> 
>> executing command: /Users/rlancaste/AstroRoot/craft-root/bin/dsymutil /Users/rlancaste/AstroRoot/craft-root/build/libs/indiserver-3rdparty-libraries/image-RelWithDebInfo-master/lib/libPlayerOnePW.1.0.0.dylib -o /Users/rlancaste/AstroRoot/craft-root/build/libs/indiserver-3rdparty-libraries/image-RelWithDebInfo-master-dbg/lib/libPlayerOnePW.1.0.0.dylib.dSYM
>> warning: no debug symbols in executable (-arch x86_64)
>> warning: no debug symbols in executable (-arch arm64)
>> error: unable to get target for 'arm64-apple-darwin', see --version and —triple.
>> 
>> You can see the same issue on the craft server here:  https://binary-factory.kde.org/view/MacOS/job/KStars_Nightly_macos/1786/consoleText
>> 
>> Thanks,
>> 
>> Rob
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20230128/b3262dee/attachment.htm>


More information about the Kstars-devel mailing list