From: Uwe K. <Uwe...@gm...> - 2022-08-23 12:07:28
|
Hello Bernd, Christopher, thank you very much for your feedback! I managed to build successfully for the x86_64 architecture. I still did not manage building for the arm64 architecture. There are two roadblocks (I use macOS 13 Ventura Beta 5) which may both be related to the configure script not resolving the target platform correctly. The target on Intel Mac is "x86_64-apple-darwin19.6.0“ —> works The target on my M1 Mac is "arm64-apple-darwin22.0.0“ —> does not work —> „windows" - my guess is the configure script cannot determine the system platform for "arm64-apple-darwin22.0.0“ and assumes „windows“ and therefore enables „-static-libgcc“ CFLAGS. This is not supported by clang and produces a fatal error. I worked araound that by commenting out the respective line in tcl.m4 - next thing is I run into arm neon errors at the link stage of libpng: (undefined symbols _png_do_expand_palette_rgb8_neon, etc…). I browsed throug the bug reports and found that in the past Linux users had reported the same issue. @Christopher: is that fixed in the SVN revision 569 that you mentioned to me and how can I download that? I noticed that in the various config.guess there is no mention of "arm" in the „Darwin“ section: *:Darwin:*:*) UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown eval "$set_cc_for_build" if test "$UNAME_PROCESSOR" = unknown ; then UNAME_PROCESSOR=powerpc fi if test "`echo "$UNAME_RELEASE" | sed -e 's/\..*//'`" -le 10 ; then if [ "$CC_FOR_BUILD" != no_compiler_found ]; then if (echo '#ifdef __LP64__'; echo IS_64BIT_ARCH; echo '#endif') | \ (CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \ grep IS_64BIT_ARCH >/dev/null then case $UNAME_PROCESSOR in i386) UNAME_PROCESSOR=x86_64 ;; powerpc) UNAME_PROCESSOR=powerpc64 ;; esac fi # On 10.4-10.6 one might compile for PowerPC via gcc -arch ppc if (echo '#ifdef __POWERPC__'; echo IS_PPC; echo '#endif') | \ (CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \ grep IS_PPC >/dev/null then UNAME_PROCESSOR=powerpc fi fi elif test "$UNAME_PROCESSOR" = i386 ; then # Avoid executing cc on OS X 10.9, as it ships with a stub # that puts up a graphical alert prompting to install # developer tools. Any system running Mac OS X 10.7 or # later (Darwin 11 and later) is required to have a 64-bit # processor. This is not true of the ARM version of Darwin # that Apple uses in portable devices. UNAME_PROCESSOR=x86_64 fi echo "$UNAME_PROCESSOR"-apple-darwin"$UNAME_RELEASE" exit ;; I do not really understand what is going on in these scripts but I am happy to try out your suggestions and keep you informed. best regards, Uwe Kirschner > On 22. Aug 2022, at 12:42, Christopher Chavez <chr...@gm...> wrote: > > Sent: Friday, August 12, 2022 at 8:20 AM > From: "Uwe Kirschner" >> Hello Andreas, >> I am struggeling very much with building a universal (x86_64/arm64) version of tkImg-1.4.13. >> >> I had not managed to build a x86_64 version either because of a missing tiffconf.h but luckily I could fallback on the prebuilt distribution. >> >> >> In file included from tifftcl.c:29: >> In file included from ./tifftcl.h:50: >> In file included from ./tifftclDecls.h:37: >> In file included from ./../compat/libtiff/libtiff/tiffio.h:31: >> ./../compat/libtiff/libtiff/tiff.h:28:10: fatal error: 'tiffconf.h' file not found >> #include "tiffconf.h" >> ^~~~~~~~~~~~ >> >> Unfortunately, there was no prebuilt universal package when I last checked (a few days ago). Do you intend to provide a prebuild universal tkImg-1.4.13? >> >> On Apple Silicon (M1 MacMini) I cannot proceed far enough to run into the missing tiffconf.h issue which had stopped me on my Intel Mac. Rather, I fail much earlier in the configure process. Looking at config.log I assume that a „windows“ platform is recognized. >> >> >> checking for tclsh... tclsh86.exe >> checking for wish... wish86.exe >> >> >> In the "tkImg-1.4.13“ directory I run: >> autoconf >> ./genConfigureScripts.sh >> ./configure —with-tcl=… —with-tk=… CFLAGS=„-arch x86_64 -arch arm64“ >> make >> >> …but no luck. Script stops due to an invalid libzlibtclstub1.2.11.a (when attempting to produce pngtcl1.6.37.dylib). I did a lipo -archs on libzlibtclstub1.2.11.a and lipo complains about an illegal fat file in the archive… >> >> >> >> Can you please have a look at the log-files and tell me what is going wrong? >> >> Best regards, >> Uwe > > > Hello Uwe, > > As I say to others who post here, the tcl-mac list is not as popular as it once was, and I would not recommend using it due to the likelihood of posts going unnoticed. Also, I am not aware of Andreas having worked on tkimg in quite some time; Jan Nijtmans and Paul Obermeier have been the ones maintaining it for several years. > > I am not familiar with Universal builds and do not have access to an Apple Silicon Mac. However I am able to build Tcl/Tk (core-8-6-branch) and tkimg (SVN revision 569, which recently fixed building libpng on arm64) without issue on macOS 10.15 Catalina using Xcode 12.4 command line tools and the macOS 11 Big Sur SDK: > > CC='xcrun --sdk /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk -r clang' \ > CFLAGS='-arch x86_64 -arch arm64' \ > ./configure … > > From looking at your config.log, I do believe something is going wrong during `checking platform`: > > configure:3395: checking platform > configure:3413: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -c -arch x86_64 -arch arm64 conftest.c >&5 > ./configure: line 1503: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang: No such file or directory > … > configure:3424: checking for cygpath > configure:3452: result: echo > configure:3464: result: windows > > I am not certain, but I believe the problem is that this step is hardcoded to use TCL_CC, and I suspect that TCL_CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang is being picked up from your tclConfig.sh. You may try overriding it as a workaround, e.g. `TCL_CC=/usr/bin/clang ./configure …`. I do not know if that is enough to allow the build to succeed for you, but if it does, then it indicates a likely issue in tclconfig rather than a Universal build issue in tkimg (I have opened a ticket in case it is the former: https://core.tcl-lang.org/tclconfig/info/c03b9df15f ) > > > Hope this helps, > Christopher A. Chavez |