Arch Linux User Repository

@xantares These are not actually mingw-w64 applications proper, but components of a Linux application that allows for discovering and loading Windows VSTs. Moving them to exotic (from the application’s point of view) locations might possibly break functionality – but I won’t even bother to go on a wild goose chase to see if it does or not. I’m not going to get into philosophical debates, either. If the scripts are unacceptable, then better have them removed.

Making guesses on what others would/had or would/had not rather do is not such a good practice as it inevitably yields unpredictable results. What I’d rather do is disown the packages or, better yet, file a removal request, as I’m not really tormented by any excruciating, irrepressible need to share with others in the first place, and continue to maintain them for my own personal needs in a way in which I can be sure they are usable – other users can manage on their own, this is Arch after all.

I’ve been maintaining these for nearly six years in order to bring unavailable Linux functionality to Arch, which was available in other distributions. The fact that I had to go through MinGW to achieve that was a major pain in the proverbial behind, but it was nothing as annoying as the struggle with bureaucracy. All things come to an end sooner or later – now is as good a time as any. While at it, I might as well ditch mingw-w64-liblo, which I’ve been maintaining without either using or needing since it ceased to be a dependency of these bridges. I say give the world what the world wants and never look back.

you're using non standard path for mingw binaries /usr/lib must not contain dlls

I think you'd rather merge carla-bridges-win64 and carla-bridges-win32 into one single package mingw-w64-carla-bridges and use standard prefixes like the other mingw-w64 packages

Thanks, my mistake for not using the precompiled bins i appreciate your time :)

The problem is that winpthreads provides bootstrap. So you don’t need the latter at all. What I suggest you should do is uninstall everything mingw and reinstall in dependency order. In order to avoid recompiling everything, please try the -bin packages that have been made available on AUR. Please take a look at the pinned comment at mingw-w64-gcc-bin for install order.

while attempting to build, i get stuck in a loop of conflicts similar to this one

this is using trizen. though i have tried other aur helpers

looking for conflicting packages... :: mingw-w64-winpthreads and mingw-w64-headers-bootstrap are in conflict. Remove mingw-w64-headers-bootstrap?

@jawkins: I will need a little more information to help. What fails, at what point, error messages, etc. I’ve just recompiled the bridges and everything went just fine.

when attempting to build im finding myself in a mingw -w64 loop i have attempted all steps in previous comments to no avail

OK, so you’re actually on Manjaro, not Arch. I propose we stop solving this here, so as not to pollute the feed with irrelevant comments; I’ll message you at the email address you provided with your account and we’ll take it from there.

Ok, thank you for your help. I do not have that installed. I cannot see that exact version of Wine in the AUR through pacman. How do I install that exact version through terminal directly?

Downgrading from A.L.A. is disabled on the stable branch. To override this behavior, set DOWNGRADE_FROM_ALA to 1 .
See https://wiki.manjaro.org/index.php?title=Using_Downgrade  for more details.

Available packages:

*  1) wine-4.0rc1-1-x86_64.pkg.tar.xz (local)
*  2) wine-3.21-1-x86_64.pkg.tar.xz (local)

also, how do i set DOWNGRADE_FROM_ALA to 1? i checked the wiki but couldn't find clear instructions.