LisaList2

Advanced search  

News:

2022.06.03 added links to LisaList1 and LisaFAQ to the General Category

Pages: 1 [2] 3 4 ... 12   Go Down

Author Topic: LisaEm 1.2.7-RC4 support bug reports  (Read 81885 times)

D.Finni

  • Sr. Member
  • ****
  • Karma: +38/-0
  • Offline Offline
  • Posts: 135
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #15 on: June 05, 2020, 02:40:47 pm »

https://lisaem.sunder.net/downloads/lisaem-1.2.7-rc1-20200527-for-macos-x-10.5-i386.pkg
This will not immediately work on 10.5 because the .plist file specifies minimum Mac OS X version 10.7.
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +105/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #16 on: June 05, 2020, 04:33:52 pm »

This will not immediately work on 10.5 because the .plist file specifies minimum Mac OS X version 10.7.

Right you are sir, fixed in the next pending release (soon, maybe today.)

Fun bit of trivia, 10.5 doesn't have a pkgbuild command, so I had to script it so the building of the 10.7 package picks up the 10.5 binaries and packages them for 10.5, but I borked it a bit and the Info.plist picked up 10.7.

I'm trying to get it to slap on the background images in the DMG so the version + release date is in the there, but but half the time it doesn't do it. Meh.

Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

D.Finni

  • Sr. Member
  • ****
  • Karma: +38/-0
  • Offline Offline
  • Posts: 135
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #17 on: June 05, 2020, 09:47:46 pm »

By the way, any update on the CPU bug that's breaking scroll bars, Workshop, etc? This seems like the highest-priority thing...
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +105/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #18 on: June 05, 2020, 10:12:10 pm »

By the way, any update on the CPU bug that's breaking scroll bars, Workshop, etc? This seems like the highest-priority thing...

I agree, it's also been the hardest to fix and so far no luck, I've got some plans to attempt resurrecting the 1.3.0 CPU engine which might have those fixed - or might introduce new bugs, not sure yet.

I've got 2-3 more features to add, I know, not supposed to add them to Release Candidates, but I think it's worth having them.

Also, I've edited the above post with new Rc1 links and also pushed the newer source code to github.

Have to retry compiling and testing on Linux and also making Windows binaries.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

Al Kossow

  • Sr. Member
  • ****
  • Karma: +35/-0
  • Offline Offline
  • Posts: 81
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #19 on: June 08, 2020, 10:51:33 am »

attempt to build on 10.11 almost works but I'm getting

ld: warning: object file (/usr/local/wx3.1.2-cocoa-x86-macOS-10.11-clang-sdl/lib/libwxjpeg-3.1.a(wxjpeg_jidctfst.o)) was built for newer OSX version (10.12) than being linked (10.11)
ld: warning: object file (/usr/local/wx3.1.2-cocoa-x86-macOS-10.11-clang-sdl/lib/libwxtiff-3.1.a(wxtiff_tif_fax3sm.o)) was built for newer OSX version (10.12) than being linked (10.11)
ld: warning: object file (/usr/local/wx3.1.2-cocoa-x86-macOS-10.11-clang-sdl/lib/libwxtiff-3.1.a(wxtiff_tif_predict.o)) was built for newer OSX version (10.12) than being linked (10.11)
Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
      wxMBConv_iconv::wxMBConv_iconv(char const*) in libwx_osx_cocoau-3.1.a(monolib_strconv.o)
      wxMBConv_iconv::ToWChar(wchar_t*, unsigned long, char const*, unsigned long) const in libwx_osx_cocoau-3.1.a(monolib_strconv.o)
      wxMBConv_iconv::FromWChar(char*, unsigned long, wchar_t const*, unsigned long) const in libwx_osx_cocoau-3.1.a(monolib_strconv.o)
      wxMBConv_iconv::GetMBNulLen() const in libwx_osx_cocoau-3.1.a(monolib_strconv.o)
     (maybe you meant: __ZN14wxMBConv_iconvC2EPKc, __ZTV14wxMBConv_iconv , __ZNK14wxMBConv_iconv5CloneEv , __ZTI14wxMBConv_iconv , __ZN14wxMBConv_iconvD0Ev , __ZN14wxMBConv_iconv14ms_wcNeedsSwapE , __ZTS14wxMBConv_iconv , __Z18new_wxMBConv_iconvPKc , __ZN14wxMBConv_iconvD1Ev , __ZNK14wxMBConv_iconv7ToWCharEPwmPKcm , __ZN14wxMBConv_iconv16ms_wcCharsetNameE , __ZN14wxMBConv_iconvC1EPKc , __ZNK14wxMBConv_iconv6IsUTF8Ev , __ZN14wxMBConv_iconvD2Ev , __ZNK14wxMBConv_iconv9FromWCharEPcmPKwm , __ZNK14wxMBConv_iconv11GetMBNulLenEv )
  "_iconv_close", referenced from:
      wxMBConv_iconv::~wxMBConv_iconv() in libwx_osx_cocoau-3.1.a(monolib_strconv.o)
  "_iconv_open", referenced from:
      wxMBConv_iconv::wxMBConv_iconv(char const*) in libwx_osx_cocoau-3.1.a(monolib_strconv.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
see: /tmp/slot.72108.1.sh /tmp/slot.72108.1.sh.failed for details
failed command was: g++ -o bin/LisaEm obj/floppy.o obj/profile.o obj/unvars.o obj/vars.o obj/glue.o obj/fliflo_queue.o obj/cops.o obj/zilog8530.o obj/via6522.o obj/irq.o obj/mmu.o obj/rom.o obj/romless.o obj/memory.o obj/symbols.o obj/lisaem_wx.o obj/LisaConfig.o obj/LisaConfigFrame.o obj/LisaSkin.o obj/hq3x-3x.o obj/imagewriter-wx.o src/lib/libGenerator/lib/libGenerator.a src/lib/libdc42/lib/libdc42.a -lstdc++.6 -L/usr/local/wx3.1.2-cocoa-x86-macOS-10.11-clang-sdl/lib -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework System -framework OpenGL /usr/local/wx3.1.2-cocoa-x86-macOS-10.11-clang-sdl/lib/libwx_osx_cocoau-3.1.a -L/opt/local/lib -lSDL2 -framework WebKit -L/opt/local/lib -lSDL2 -lwxtiff-3.1 -lwxjpeg-3.1 -lwxpng-3.1 -lwxregexu-3.1 -lwxscintilla-3.1 -lwxzlib-3.1 -framework Security -lpthread -liconv
from: /Users/aek/git/__rayarachelian/lisaem
---------------------------------------------------------------

/Users/aek/git/__rayarachelian/lisaem/waitq: Aborted due to a failed job! See /Users/aek/git/__rayarachelian/lisaem/obj/build-warnings.txt
* Exiting
make: *** [build] Error 9


--

don't quite understand the undefined symbols, or why it decided to build for 10.12
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +105/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #20 on: June 08, 2020, 11:11:10 am »

That smells like a linking ordering issue, can you try running this?
Code: [Select]
g++ -o bin/LisaEm -lpthread -liconv obj/floppy.o obj/profile.o obj/unvars.o obj/vars.o obj/glue.o obj/fliflo_queue.o obj/cops.o obj/zilog8530.o obj/via6522.o obj/irq.o obj/mmu.o obj/rom.o obj/romless.o obj/memory.o obj/symbols.o obj/lisaem_wx.o obj/LisaConfig.o obj/LisaConfigFrame.o obj/LisaSkin.o obj/hq3x-3x.o obj/imagewriter-wx.o src/lib/libGenerator/lib/libGenerator.a src/lib/libdc42/lib/libdc42.a -lstdc++.6 -L/usr/local/wx3.1.2-cocoa-x86-macOS-10.11-clang-sdl/lib -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework System -framework OpenGL /usr/local/wx3.1.2-cocoa-x86-macOS-10.11-clang-sdl/lib/libwx_osx_cocoau-3.1.a -L/opt/local/lib -lSDL2 -framework WebKit -L/opt/local/lib -lSDL2 -lwxtiff-3.1 -lwxjpeg-3.1 -lwxpng-3.1 -lwxregexu-3.1 -lwxscintilla-3.1 -lwxzlib-3.1 -framework Security

and see if it links it?

If it helps, my 10.11 is 10.11.5.
xcode-select -p shows the full XCode 7.2 install, i.e.:
/Applications/Xcode.app/Contents/Developer

Which is likely where the 10.12 stuff came from, not sure why wxWidgets was linked against the later 10.12 SDK.

 gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.5.0
Thread model: posix

Just tried building it against wx3.1.2, and in obj/build-errors.txt this is the linking text I get:

Code: [Select]
---------------------- /tmp/slot.881.39.sh.done ----------------------- g++ -o bin/LisaEm obj/floppy.o obj/profile.o obj/unvars.o obj/vars.o obj/glue.o obj/fliflo_queue.o obj/cops.o obj/zilog8530.o obj/via6522.o obj/irq.o obj/mmu.o obj/rom.o obj/romless.o obj/memory.o obj/symbols.o obj/lisaem_wx.o obj/LisaConfig.o obj/LisaConfigFrame.o obj/LisaSkin.o obj/hq3x-3x.o obj/imagewriter-wx.o src/lib/libGenerator/lib/libGenerator.a src/lib/libdc42/lib/libdc42.a -lstdc++.6 -L/usr/local/wx3.1.2-cocoa-x86-macOS-10.11-clang-sdl/lib -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework System -framework OpenGL /usr/local/wx3.1.2-cocoa-x86-macOS-10.11-clang-sdl/lib/libwx_osx_cocoau-3.1.a -llzma -framework WebKit -lwxtiff-3.1 -lwxjpeg-3.1 -lwxpng-3.1 -lwxregexu-3.1 -lwxscintilla-3.1 -lwxzlib-3.1 -llzma -framework Security -lpthread -liconv -llzma
in: /Volumes/shared/code/lisaem-1.2.7
!!* Linked ./bin/LisaEm

Now, if I run the linking command you've pasted, I get an error saying that /opt/local/lib doesn't exist (it doesn't in my VM, which is fine). I'm guessing that somehow that snuck in somewhere and possibly one of the libraries in /opt/local/lib got included which may be causing an issue, not sure, but that might be something to look at as well. Is that from Darwin Ports? I'm using brew on this vm, but ports on older macos:

Code: [Select]
elcapitan:lisaem-1.2.7 ray$ g++ -o bin/LisaEm obj/floppy.o obj/profile.o obj/unvars.o obj/vars.o obj/glue.o obj/fliflo_queue.o obj/cops.o obj/zilog8530.o obj/via6522.o obj/irq.o obj/mmu.o obj/rom.o obj/romless.o obj/memory.o obj/symbols.o obj/lisaem_wx.o obj/LisaConfig.o obj/LisaConfigFrame.o obj/LisaSkin.o obj/hq3x-3x.o obj/imagewriter-wx.o src/lib/libGenerator/lib/libGenerator.a src/lib/libdc42/lib/libdc42.a -lstdc++.6 -L/usr/local/wx3.1.2-cocoa-x86-macOS-10.11-clang-sdl/lib -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework System -framework OpenGL /usr/local/wx3.1.2-cocoa-x86-macOS-10.11-clang-sdl/lib/libwx_osx_cocoau-3.1.a -L/opt/local/lib -lSDL2 -framework WebKit -L/opt/local/lib -lSDL2 -lwxtiff-3.1 -lwxjpeg-3.1 -lwxpng-3.1 -lwxregexu-3.1 -lwxscintilla-3.1 -lwxzlib-3.1 -framework Security -lpthread -liconv
ld: warning: directory not found for option '-L/opt/local/lib'
ld: warning: directory not found for option '-L/opt/local/lib'
ld: library not found for -lSDL2
clang: error: linker command failed with exit code 1 (use -v to see invocation)
elcapitan:lisaem-1.2.7 ray$

If I remove /opt/local/lib from that command, instead, I get complaints about lzma, and removing  -lwxzlib-3.1 throws other errors.
Code: [Select]
Undefined symbols for architecture x86_64:
  "_lzma_code", referenced from:
      _LZMADecode in libwxtiff-3.1.a(wxtiff_tif_lzma.o)
      _LZMAPostEncode in libwxtiff-3.1.a(wxtiff_tif_lzma.o)
      _LZMAEncode in libwxtiff-3.1.a(wxtiff_tif_lzma.o)
  "_lzma_end", referenced from:
...

Not sure how to get closer to your setup. I'd say check to ensure xcode-select -p shows XCode 7.2, worst case try to rebuild wxWidgets maybe tweaking the build-wx3.1.2-macos script disabling any libs you don't need. If you run ../configure --help in the wxWidgets build directory and look for both with and without options, see what else can be disabled, or set to builtin.

The one I shipped in rc1 is linked against wx3.1.3 - you can modify the build-wx3.1.2 to build both 3.1.2 and 3.1.3 like so at line 15:
Code: [Select]
for VER in 3.1.3 3.1.2; do

Pls let me know what winds up working for you (or not).

« Last Edit: June 08, 2020, 12:05:55 pm by rayarachelian »
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

Al Kossow

  • Sr. Member
  • ****
  • Karma: +35/-0
  • Offline Offline
  • Posts: 81
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #21 on: June 08, 2020, 12:25:26 pm »

I use ports, which is no doubt where the /opt/local/.. stuff comes from

Then, I have a different tool chain for building MAME

sigh..

Logged

Al Kossow

  • Sr. Member
  • ****
  • Karma: +35/-0
  • Offline Offline
  • Posts: 81
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #22 on: June 08, 2020, 12:28:24 pm »

just noticed at the start of the build

--

aek$ ./*modern*
MIN_MACOSX_VERSION: 10.12

Logged

Al Kossow

  • Sr. Member
  • ****
  • Karma: +35/-0
  • Offline Offline
  • Posts: 81
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +105/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #24 on: June 08, 2020, 02:04:21 pm »

Can you check that script for this snip? I think it's there since it does produce that output, but want to make sure.
It should ask XCode for what it supports. Might be it needs a slightly earlier XCode version that targets for 10.11 instead.

Code: [Select]
#!/usr/bin/env bash

OSVER="$( sw_vers -productVersion | cut -f1,2 -d'.' )"

export MIN_MACOSX_VERSION="$(  xcodebuild -showsdks 2>/dev/null | grep macosx10 | cut -d'-' -f2 | sed -e 's/sdk macosx//g' | sort -n | head -1 )"
[[ -z "$MIN_MACOSX_VERSION" ]] && export MIN_MACOSX_VERSION="$( basename $(ls -1d $(xcode-select -p )/SDKs/* | grep -i macosx10 | sort -n | head -1 ) | sed -e 's/.sdk$//g' -e 's/[Mm]ac[Oo][Ss][Xx]//g' )"
[[ -z "$MIN_MACOSX_VERSION" ]] && export MIN_MACOSX_VERSION="$OSVER"

OSVER="macOS-$( sw_vers -productVersion | cut -f1,2 -d'.' )"

echo "MIN_MACOSX_VERSION: $MIN_MACOSX_VERSION"
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

Al Kossow

  • Sr. Member
  • ****
  • Karma: +35/-0
  • Offline Offline
  • Posts: 81
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #25 on: June 08, 2020, 03:25:58 pm »


"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.
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +105/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #26 on: June 08, 2020, 07:36:59 pm »

I don't think they could they have made backwards development compatibility any more difficult.

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.
« Last Edit: June 08, 2020, 07:46:42 pm by rayarachelian »
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

Al Kossow

  • Sr. Member
  • ****
  • Karma: +35/-0
  • Offline Offline
  • Posts: 81
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #27 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
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +105/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #28 on: June 09, 2020, 12:15:06 pm »

it would be nice if you could explicitly add which libiconv lisaem is expecting
anyone using macports is going to trip over this

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.)
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +105/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #29 on: June 09, 2020, 10:26:55 pm »

Looks like all macosx'en have this path: /usr/lib/libiconv.2.dylib so hopefully that will do the trick.

Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code
Pages: 1 [2] 3 4 ... 12   Go Up