Arch Linux User Repository

(follow-up) - yeah, currently it's a bit of a mess :

• I found permalinks, like https://ltspice.analog.com/download/24.1.0/LTspice64.msi
• the above is the same file as what you currently (2025/01/25) get from https://ltspice.analog.com/software/LTspice64.msi
• the version string in the .json file is not 24.1.0 as expected, but '24.0.12' ....
• if you download https://ltspice.analog.com/download/24.0.12/LTspice64.msi, the .json says 24.0.11...

I'm going to try using a permalink, just so the build doesn't break on their next update, but I may not notice for a while to update the PKGBUILD. We can revisit this if analog gets their versioning straightened out.

Thanks for the hint dreieck, I moved the download of files into the prepare section as they change unpredictably depending on the file listing from the LTSpice website.

In your PKGBUILD, you explicitly download stuff in build().

However, it is not recommended if stuff can already be downloaded via source-array or in prepare(), so that once makepkg -o is done no internet connection is needed to build the software.

Ideally, you could transfer all needed downloads to the source-array (the array beeing built "on the fly" by parsing "${_update_url}/release.log.gz"), or if that does not really work move the relevant parts now in build() into prepare().

Thanks for maintaining!

==> Starting build()...
Checking cache and downloading using 16 threads.
Starting...
Download Progress: 5957/9785 (lib/sym/Comparators/LTC6754.asy)
[...]

Thanks a lot lightspot21!

I have found that running wine /usr/lib/wine/start.exe /unix /opt/ltspice/XVIIx64.exe works as well and without the need to modify the prefix, so I will include that in the launcher script until the new wine version with the bugfix is released. Thanks again!

Reposting due to accidental deletion.

So I went to hunt the issue behind the breakage:

I tried to run the 64-bit executable directly, just like the shell script. No WINEPREFIX set yet. wine /opt/ltspice/XVIIx64

and I get back the error: wine: failed to open L"/opt/ltspice/XVIIx64": c0000135

Attempting to "fake" the first run, I deleted the prefix and started anew: export WINEPREFIX=$HOME/.ltspice/env WINEARCH=win64 && wine /opt/ltspice/XVIIx64 but the error persisted.

With the same prefix, but calling wine /opt/ltspice/XVIIx64.exe the error changes to: wine: failed to load start.exe: 40000003

Googling it took me to this issue: https://bugs.winehq.org/show_bug.cgi?id=50867 , where the workaround was to copy start.exe from the command dir of the prefix to the system32 dir, then use wine start /unix /opt/ltspice/XVIIx64.exe with the correct prefix set to run the 64 bit version. This is because:

What has changed is that Wine is more strict about requiring the 
file to execute to actually be found on disk. By default, start.exe
is installed into c:\windows\command, which is not in the standard path, 
so it isn't found.

The bug is already fixed in the next version of Wine.

I have tried multiple combinations of running the application but can't get it to work right now. I will sticky your workaround for now and if I find the time I'll figure out whether something is wrong with the launcher script.

Downgrading wine should also be a workaround but I haven't tried that.

@bigdino wine /opt/ltspice/XVIIx86.exe keeps doing it for me now that I tried it, even after a desktop session logout. Not sure whether this was your exact command but at least I guess I got myself a temporary workaround that hasn't failed yet.

Same issue on my side as the previous comment.

I somehow managed to start LTSpice yesterday by calling /opt/ltspice/XVIIx86, but for some reason I can't start it anymore today.

I made an update today and now LTSpice doesn't open. Might be because wine was updated yesterday.

When I type ltspice on the terminal, this is the output:

failed to open L"/opt/ltspice/XVIIx64": c0000135