Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
71 user(s) are online (49 user(s) are browsing Forums)

Members: 0
Guests: 71

more...

Support us!

Headlines

Forum Index


Board index » All Posts (MickJT)




Re: MPlayer 1.5 released!
Quite a regular
Quite a regular


Quote:
samo79 wrote:
@ktadd

Maybe its due to FFMpeg, the latest version we use for 1.5 may be slower


I was using -O4 (mplayer's source uses that by default) rather than -O2. I think that would make a noticeable difference. A quick google search says that -O4 is the same as -O3, and probably reserved for future purposes.


Edited by MickJT on 2024/4/28 18:18:19
Go to top


Re: MPlayer 1.5 released!
Quite a regular
Quite a regular


@Gerbrochen

http://os4depot.net/?function=showfile&file=video/play/mplayer.lha

It's an update / continuation of my port. Mine was based off of LiveForIt's port, and his was based off of afxgroup's port. I'm probably missing some names.

In short, unless you have a good reason to keep using mine, use the new one.

Go to top


Re: AmiUpdate Passwords
Quite a regular
Quite a regular


Hmm, it doesn't appear to be autosaved.

The file is called SiteList, in the same path as the main AmiUpdate executable

It has 3 lines

AmigaOSUpdateServer
yourusername
yourpassword

Go to top


Re: AmiUpdate 2.50
Quite a regular
Quite a regular


@Rigo

By that I guess you mean I should have been using the bugtracker to make a report.

@nbache

Good old tcpdump

Go to top


Re: AmiUpdate 2.50
Quite a regular
Quite a regular


Version 2.54, but it definitely seems server side. Every package has the existingonly="1" flag.

Go to top


Re: AmiUpdate 2.50
Quite a regular
Quite a regular


I've spotted a server side issue.

Regardless of the "Update Existing" option set on the web interface when uploading a package, it treats it as if "Update Existing" is always ticked, meaning a package must already be installed in order for an update to show up.

Go to top


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



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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project