Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
62 user(s) are online (33 user(s) are browsing Forums)

Members: 0
Guests: 62

more...

Headlines

Forum Index


Board index » All Posts (MickJT)




Re: SDL2
Quite a regular
Quite a regular


That's a headache if libSDL2_net, _ttf, _gfx etc were updated at different times with different SDL2 versions. Sure you can make softlinks of previous versions that all link to the latest SDL2 .so, but it doesn't look nice aesthetically. For most libraries, I try to use library.so.majornum for the soname, so newer versions can be just a drop in replacement. I use version_type=qnx in libtool for that. (Edit: Although this doesn't appear to have an effect anymore for SDL2 libs, see edit at the bottom of the post).

I know the solution is to update every SDL2 library all at the same time, but then there's still all the programs too, which could be ported by various different people, and might not include the .so files inside the archive.

Fortunately just about everything is linked statically and ScummVM is one of the only exceptions, and includes the required files in the archive, so it's not a huge deal.

Edit: I see that on OS4Depot my last ports of SDL2_image and SDL2_ttf use the sonames of libSDL2_image-2.0.so.600 and libSDL2_ttf-2.0.so.2000. Usually these are only dependencies of the main binary of whatever is being compiled, and not of other libraries, so it shouldn't be too much of an issue, but nevertheless it's something for me to consider. I don't think version_type=qnx stops it with the SDL2 libs.


Edited by MickJT on 2024/3/16 12:46:50
Edited by MickJT on 2024/3/16 12:51:58
Edited by MickJT on 2024/3/16 12:53:09
Edited by MickJT on 2024/3/16 12:58:08
Edited by MickJT on 2024/3/16 13:02:42
Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@Raziel

That's interesting. If this is the first time you've seen the compiler mention libpthread.so, then I'm guessing it's not being used by anything else and perhaps the reason for the crash wasn't libpthread.a being accidentally embedded in libcurl.so.12, but some other reason. Anyway, all that matters is the problem got solved! I'll update libcurl on OS4Depot within a couple of weeks, but keep the .so.12 you have because it uses DEVS:AmiSSL/Certs while the OS4Depot version will use curl-ca-bundle.crt

Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@Raziel

Emailed

Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@joerg

I think the threaded resolver will work (Futaura committed a bunch of AmigaOS specific patches for 7.85, and some of the threaded resolver stuff I think was based on your own work, but then worked on some more to support features in later versions of Roadshow). I think the issue Maijestro was having was because I had accidentally linked libpthread.a with libcurl.so.12, and another library used libpthread.so so you ended up with 2 different libpthreads being used.

Waiting for Maijestro to report back if the last .so I sent works properly.


Edited by MickJT on 2024/2/26 13:19:12
Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@Raziel

I'm guessing you have that crt file in S:?


@joerg

S:curl-ca-bundle.crt is what's defined for CURL_CA_BUNDLE in config-amigaos.h (although that header file isn't used in the OS4 port) so I just used that, and an env variable should be able to override that. It's not defined at all by default, and I'm not sure if there's any default path when it's not defined. I can make it use the AmiSSL certs but then (in my past experience) there's no way to override that with env variables to force it to use a cert bundle file. I don't mind building libcurl with custom compile time options for ScummVM though.


@Maijestro

Soon, I'll be re-enabling the threaded resolver and make libcurl use AmiSSL certs. I'll edit this post when I've done that.

Edit: Done. Check your messages.

Also, I've noticed that -g isn't used by default when compiling libcurl, so it'd be missing debug symbols. If there's further issues, I'll add -g


Edited by MickJT on 2024/2/26 2:30:56
Edited by MickJT on 2024/2/26 2:36:31
Edited by MickJT on 2024/2/26 3:56:56
Edited by MickJT on 2024/2/26 4:32:44
Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


It's the ability to look up IP addresses for multiple hostnames without waiting for a lookup to finish before it can lookup another. I'm not sure if other network activity also gets paused during domain lookups when threaded resolving is off.

There's platform specific code (including AmigaOS) in libcurl for threaded resolving. I'll turn it back on and send you a new .so to test tomorrow.

Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@Maijestro

If you have that crt bundle file (can probably find one that comes with Odyssey), just put it in S: and see if that works.

Also in the new .so I sent you, I had disabled threaded resolving. So I'll want to send you at least one more version of the library for you to test, soon.

Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@Maijestro

Check private messages.

Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


I'll build libcurl on the weekend with a couple of different compile time options, and that can be tested to see if that helps.

Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


Is it still the same address in the stack trace? 0x7A3BAEF0 ? If I use ppc-amigaos-addr2line -e libcurl.so.12 -j .text 0x7A3BAEF0 I only get "??:0" which doesn't help! And libcurl.so.12 should be built with debug symbols.

I don't know what you mean by "additional protocols".

Perhaps updating libcurl again will magically fix things. I'll look at that later. .... but to be clear, there's no problem when you don't run Odyssey first?

I also don't know how you managed to get this info in post #492:

Stack trace:
(0x66BD2C20) [audio/softsynth/mt32/srchelper/srctools/src/SincResampler.cpp:64] scummvm:_ZN8SRCTools13SincResampler5Utils22computeResampleFactorsERjRdddj()+0x324 (section 10 @ 0xDE9FB0)
(0x66BD2C50) module Download:Testen/TestScummVM/sobjs/libcurl.so.12 at 0x7A3BAEF0 (section 0 @ 0x8AA94)

If I run

ppc-amigaos-addr2line -e scummvm -j .text 0xDE9FB0 I also get ??:0, but scummvm is built without debug symbols. Were you using a different scummvm binary than the one on OS4Depot?

Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


So. It only crashes after you've been running something else like Odyssey or YT.rexx? I also use WinUAE and get crashes sometimes that didn't occur on real hardware (unfortunately I don't have working real hardware to test on anymore). I haven't tried running ScummVM myself yet.

Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


I'm so confused. So have you tested ScummVM with a high stack size with libcurl.so.12, or not? I thought your video was showing everything working fine with libcurl.so.12

Mismatching .so files can cause all sorts of problems. For example, libcurl.so.11 will be looking for libcrypto.so.1 and libssl.so.1, not libcrypto.so.3 and libssl.so.3. Also, libcurl.so.12 is built against OpenSSL v3, not OpenSSL v1.1. Also the latest build of librtmp.so.1 should be expecting OpenSSL v3 libraries as well.

Files in PROGDIR:SObjs/ will be found before it looks in SYS:SObjs/. Everything needed for ScummVM should be in PROGDIR:SObjs/

If you've been renaming things or moving files around in a way where the newer libcurl is trying to use the older openssl, it might not be ABI compatible and cause crashes.

So if you haven't tried ScummVM with all the intended files (no files renamed or overwritten, and nothing from SYS:SObjs/ being used), and with a high stack size, then please try that. That was the point of the test, to see if a higher stack size fixes the issue.

Also, you said the crash was always within libcurl, but is it always the same address space within libcurl? I tried checking what address 0x7A3BAEF0 and 0x7A3BAEE0 were in libcurl.so.12 using addr2line but they don't seem to be valid, making me think the issue was memory corruption or something similar (sometimes all that's needed to fix a DSI is a higher stack size). From the sounds of it, there's no problem unless you're running Odyssey/YT first.

I'm assuming you're on the latest OS4.1 FE (Update 2 + updates)?


Edited by MickJT on 2024/2/20 20:15:10
Edited by MickJT on 2024/2/20 20:22:25
Edited by MickJT on 2024/2/20 20:50:31
Reason: updated hex addresses
Go to top


Re: NetSurf 3.11 has been released!
Quite a regular
Quite a regular


@Chris

FYI, the command line version of curl uses AmiSSL. I was going to suggest testing the openssl binary from libopenssl.lha using s_client but that wouldn't be testing the connection / resolver code of libcurl.

These days libcurl should be easy to port with no source modifications needed. Choose --with-openssl when configuring (and make sure the openssl headers in your compiling environment are the right ones) and the resulting curl binary will use OpenSSL.


Edited by MickJT on 2024/1/3 12:25:14
Go to top


Re: YT stopped working with Odyssey - Fixed
Quite a regular
Quite a regular


@ktadd

An e-mail I got in September from one of the people working on MPlayer reported that it was crashing with an up to date libass but not an old one, but it's ok with ffmpeg. I don't have any more info about it.

Go to top


Re: YT stopped working with Odyssey - Fixed
Quite a regular
Quite a regular


@Maijestro

-nofontconfig is a runtime option, which can be used if mplayer is compiled with fontconfig support.

Using >NIL: *>NIL: should suppress all output, but on the port you're using, you should be able to use -nofontconfig as a command line option in ArgsMP

Go to top


Re: YT stopped working with Odyssey - Fixed
Quite a regular
Quite a regular


@ktadd

It's been a while since I compiled that, so I don't remember clearly, but I probably compiled it without fontconfig support, but with libass support, and libfontconfig would be a dependency of libass so the binary is still technically linked against libfontconfig. Perhaps in certain cases libfontconfig might be used, such as when using .ass subtitles?

Go to top


Re: YT stopped working with Odyssey - Fixed
Quite a regular
Quite a regular


@Maijestro

Quote:
There is always a small window with the error message "Fontconfig error" but the YouTube stream is playing.


If I remember right, that's a message from libfontconfig written to stderr. It should go away if it finds a valid fonts.conf.

In the screenshot you provided, it looks like the port of libfontconfig being used wanted to find it in .config:fontconfig/fonts.conf, so if you make an assign called ".config:" and put a fontconfig directory there and fonts.conf in there (try copying the one from SYS:Fonts/fontconfig), then the message hopefully goes away.

Maybe also delete this line (make a backup though)
<include ignore_missing="yes">fonts:fontconfig/conf.d</include>

Alternatively you can use *>NIL: to redirect stderr, and you should be able to set that in YT.cfg in ArgsMP, but that would end up suppressing other error messages that you might not want suppressed.


Edited by MickJT on 2023/12/19 3:37:11
Edited by MickJT on 2023/12/19 3:40:48
Edited by MickJT on 2023/12/19 3:43:01
Edited by MickJT on 2023/12/19 3:50:30
Edited by MickJT on 2023/12/19 4:04:10
Go to top


Re: SDL2
Quite a regular
Quite a regular


@Capehill

I tried my old port of ffmpeg 3.1.1 which is on Aminet, and that uses SDL1 rather than SDL2. I don't know which version of the SDL1 library I built it against. In that version, the pointer is a different black pointer when inside the window, and only disappears when kept motionless inside the window. When outside, it's the regular mouse pointer, and doesn't disappear.

Maybe looking at the SDL1 source might help.


Edited by MickJT on 2023/12/6 13:20:37
Go to top


Re: SDL2
Quite a regular
Quite a regular


@Capehill

Quote:
I have tested on Linux that SDL_MOUSEMOTION behaves similarly: event is reported only when mouse pointer is hovering on the window surface.


This confuses me a bit. Wouldn't then the same behaviour happen with the mouse disappearing even if outside of the window? Or is the behaviour different between Windows and Linux?

@pjs

In the meantime, I have updated ffplay to not hide the mouse cursor.


Edited by MickJT on 2023/12/6 6:24:42
Go to top


Re: SDL2
Quite a regular
Quite a regular


@Capehill

I've tested it on Windows. I don't think ffplay has any alternative output method, just SDL2, so it should still be SDL2 on Windows.

When the mouse is outside of the window, it won't blank, even when the ffplay window is active.

Go to top



TopTop
(1) 2 3 4 ... 47 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project