General Category > LisaList2
LisaEm 1.2.7-RC4 support bug reports
Al Kossow:
"Might be it needs a slightly earlier XCode version"
Likely. My configuration is very different
aek$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
--
I don't think they could they have made backwards development compatibility any more difficult.
rayarachelian:
--- Quote from: Al Kossow on June 08, 2020, 03:25:58 pm ---I don't think they could they have made backwards development compatibility any more difficult.
--- End quote ---
Yeah, it's on purpose, so you keep your systems up to date until they no longer support them, and then have to buy newer machines.
If you have access to older XCode from an older OS, you should be able to copy the SDK files for macos x in the same directory and use those to compile against. It mostly should work: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
You could also rename the XCode.app file and download an older XCode and then install it and move its SDK that way, if you're a registered developer with Apple, which is a free process.
The wxWidgets configure command will accept something like -min-macosx=10.10 or similar, but has to have that SDK available.
There's a good chart here: https://en.wikipedia.org/wiki/Xcode#Version_comparison_table that shows which XCode will run on which macos and more importantly produce proper binaries for. So you'd want XCode 7.2 or 7.3. Worse, you'll have figure out which command line tools to download as well and have that match, which is yet another annoyance to deal with.
It's possible, for example, to get a new XCode that happily runs on 10.11 but only has the 10.12 SDK and doesn't build binaries for 10.11.
In practice the binaries will most likely still work, but you'll get warnings on linking as you saw.
Al Kossow:
it would be nice if you could explicitly add which libiconv lisaem is expecting
anyone using macports is going to trip over this
rayarachelian:
--- Quote from: Al Kossow on June 09, 2020, 11:12:42 am ---it would be nice if you could explicitly add which libiconv lisaem is expecting
anyone using macports is going to trip over this
--- End quote ---
I'm not directly using any iconv, I'm using wxWidgets, which in turn will make calls against whatever libiconv its configure script decided to link against. That decision shouldn't be changed between compiling wxWidgets and LisaEm, but I can't control for that. That's the point of a cross platform GUI framework and statically linking it - not having to specify such things. I'm expecting a mostly vanilla os, though yes, on elder macos such as 10.5-10.7 I do use ports and on newer ones I use brew - but this is mostly for updating tools, and less for libs to be used by LisaEm.
Infact, I go out of my way to specify builtin in the wxWidgets scripts for things like png, jpg, tiff, etc. just to avoid such situations. It's not that my system doesn't have libjpg or whatever, but more I don't want have to depend on that version when distributing binaries.
Since you're building for yourself, it doesn't matter if it's static or dynamic wxWdigets, but then that copy of LisaEm can't be moved to another system that has a different setup.
In your case, I think the issue is that wxWidget's configure decided to pick up a specific libiconv that LisaEm's build script did not see or have in it's library path, causing the issue, or somehow wx-config did not pass the appropriate -L -l flags which then build.sh passed to gcc/ld. Possibly because port inserts its own paths first, etc., and I'm sure brew does things like that too.
You can fix this by forcing wxWidgets to use a specific iconv like so by changing the script/build-wx3.1.2-modern-macos.sh to pass these:
../configure --help | grep -i iconv
--with-libiconv use libiconv (character conversion)
--with-libiconv-prefix=DIR search for libiconv in DIR/include and DIR/lib
And hopefully wx-config --libs might then give the right libs and fix the issue.
I can add those in the next push/rc, but I'll first have to ensure they work on all systems - or insert logic to detect which to use, which is painful.
There's some discussion here: https://wiki.wxwidgets.org/Distributing_WxWidgets_Applications-Distributing_WxMac_Programs - (but this is from a very old wxWidgets version in that discussion as unicode is now mandated in wx3.x, but he runs into the same kind of issues.)
rayarachelian:
Looks like all macosx'en have this path: /usr/lib/libiconv.2.dylib so hopefully that will do the trick.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version