Package Details: carla-bridges-win64-git 6278.975821819-1

Git Clone URL: https://aur.archlinux.org/carla-bridges-win64-git.git (read-only, click to copy)
Package Base: carla-bridges-win64-git
Description: Carla win64 bridge
Upstream URL: http://kxstudio.sf.net/carla
Licenses: GPL2
Conflicts: carla-bridges-win64
Provides: carla-bridges-win64
Submitter: Joermungand
Maintainer: Joermungand
Last Packager: Joermungand
Votes: 8
Popularity: 0.000034
First Submitted: 2014-10-26 21:29 (UTC)
Last Updated: 2022-03-16 08:32 (UTC)

Pinned Comments

Latest Comments

Joermungand commented on 2020-07-03 13:30 (UTC)

@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.

xantares commented on 2020-07-03 11:22 (UTC)

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

jawkins commented on 2019-01-17 21:35 (UTC)

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

Joermungand commented on 2019-01-17 18:20 (UTC) (edited on 2019-01-17 18:21 (UTC) by Joermungand)

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.

jawkins commented on 2019-01-17 16:24 (UTC)

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?

Joermungand commented on 2019-01-16 10:26 (UTC)

@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.

jawkins commented on 2019-01-16 00:09 (UTC)

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

Joermungand commented on 2018-12-17 18:29 (UTC)

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.

Ikshvaku commented on 2018-12-17 18:19 (UTC) (edited on 2018-12-17 18:22 (UTC) by Ikshvaku)

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.

Joermungand commented on 2018-12-17 17:47 (UTC) (edited on 2018-12-17 17:48 (UTC) by Joermungand)

Seeing that you have already been able to start compilation, I assume you’ve already got the latest wine installed. What you need is downgrading it to an older version. There are two ways to go about it (please replace wine with wine-staging in the following if that’s the version of wine you have):

(1) Install from cache (assuming you had wine 3.20 at some point in the past):

# pacman -U /var/cache/pacman/pkg/wine-3.20-1-x86_64.pkg.tar.xz

(2) If you’ve never had wine 3.20 installed, the command above will not work. Then you need to use downgrade (you can install it from AUR). Once installed, all it takes is

downgrade wine

and select the appropriate version in the list it displays.

Please post back if you need any help.

Ikshvaku commented on 2018-12-17 17:23 (UTC)

can you please tell me how i can install the correct version of wine through terminal using pacman?

Joermungand commented on 2018-12-17 07:56 (UTC)

PlayonLinux has no influence on the compilation. The versions of Wine it maintains are restricted to its own functionality. The only thing that matters is the system version of Wine (i.e. the one that pacman can see) – that’s the one that should be downgraded to 3.20.

Ikshvaku commented on 2018-12-16 21:40 (UTC)

Could the issue be that I installed Wine through PlayonLinux? Do you have any other ideas of what I can try?

Joermungand commented on 2018-12-16 19:21 (UTC) (edited on 2018-12-16 19:26 (UTC) by Joermungand)

Well, other than recompiling the whole mingw chain (not funny, it takes a little to complete), I fail to see any difference. I’ve build it severally, with both wine and wine staging, and had no issue. For the code, enclose it within triple backticks (with the backticks on a line of their own):

Compiling JackBridge1.cpp (wine64) In file included from ../utils/CarlaUtils.hpp:26, from ../utils/CarlaLibUtils.hpp:21, from JackBridge1.cpp:32: /usr/include/c++/8.2.1/cstdlib:75:15: fatal error: stdlib.h: No such file or directory #include_next <stdlib.h> ^~~~~~~~~~ compilation terminated. winegcc: gcc failed make[1]: [Makefile:215: ../../build/jackbridge/Release/JackBridge1.cpp.wine64.o] Error 2 make[1]: Leaving directory '/var/tmp/pamac-build-anzick/carla-bridges-win64-git/src/carla-bridges-win64-git/source/jackbridge' make: [Makefile:219: wine64] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

Ikshvaku commented on 2018-12-16 13:29 (UTC) (edited on 2018-12-16 13:33 (UTC) by Ikshvaku)

Just tried again with Wine 3.20 and then with 3.2-staging and still same thing...(how do i put code in that neat blue box?)

Compiling JackBridge1.cpp (wine64) In file included from ../utils/CarlaUtils.hpp:26, from ../utils/CarlaLibUtils.hpp:21, from JackBridge1.cpp:32: /usr/include/c++/8.2.1/cstdlib:75:15: fatal error: stdlib.h: No such file or directory #include_next <stdlib.h> ^~~~~~~~~~ compilation terminated. winegcc: gcc failed make[1]: [Makefile:215: ../../build/jackbridge/Release/JackBridge1.cpp.wine64.o] Error 2 make[1]: Leaving directory '/var/tmp/pamac-build-anzick/carla-bridges-win64-git/src/carla-bridges-win64-git/source/jackbridge' make: [Makefile:219: wine64] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

Joermungand commented on 2018-12-16 06:02 (UTC)

I cannot reproduce, sorry. It builds just fine here with both wine-staging-3.20 and wine-3.20. The only other thing I did while trying to trace the error was recompile all mingw packages and dependencies (well, dependencies first), but, at that time, they turned out not to be the cause.

Ikshvaku commented on 2018-12-16 03:30 (UTC)

I am having the same issue as Teteros. I tried downgrading my version of wine and it still had the same error, unfortunately.

Joermungand commented on 2018-12-07 07:10 (UTC)

I have finally managed to find the culprit: it’s wine – it needs downgrading to 3.20. Then the bridges will build just fine.

Teteros commented on 2018-12-03 01:07 (UTC)

I'm getting a missing include during jackbridge makefile

make -C source/jackbridge wine64
make[1]: Entering directory '/home/tete/code/aursrc/carla-bridges-win64-git/src/carla-bridges-win64-git/source/jackbridge'
Compiling JackBridge2.cpp (wine64)
Compiling JackBridge3.cpp (wine64)
Compiling JackBridge1.cpp (wine64)
In file included from ../utils/CarlaUtils.hpp:26,
                 from ../utils/CarlaSemUtils.hpp:21,
                 from JackBridge2.cpp:22:
/usr/include/c++/8.2.1/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
compilation terminated.
winegcc: gcc failed
make[1]: *** [Makefile:215: ../../build/jackbridge/Release/JackBridge2.cpp.wine64.o] Error 2

Joermungand commented on 2017-11-19 12:24 (UTC)

Thanks, falkTX, both 32- and 64-bit bridges updated.

falkTX commented on 2017-11-18 19:23 (UTC)

to maintainer: please remove vstsdk, it's no longer used in the latest version. (vst3 support dropped)

Joermungand commented on 2017-03-18 16:16 (UTC)

I didn’t know that, thanks. I’ve always relied on yaourt for that, which doesn’t seem to do that (except in case of error) even if I use ~/.tmp as a temporary directory.

SpotlightKid commented on 2017-03-18 15:34 (UTC)

Right, but it would affect probably all pacaur users, since it keeps the sources between updates (at least here).

Joermungand commented on 2017-03-18 12:42 (UTC)

Corrected. I never get that error as I always make clean builds, sorry.

SpotlightKid commented on 2017-03-17 14:24 (UTC)

Line 47 in the PKGBUILD file should start with "ln -sf" instead of just "ln -s", otherwise I get an error when building the package and I already have built it before. ln: failed to create symbolic link 'source/includes/vst2/VST3 SDK': File exists ==> ERROR: A failure occurred in build(). Aborting...

GraysonPeddie commented on 2017-03-11 02:46 (UTC)

Pardon my delay, but thanks!

Joermungand commented on 2017-03-10 14:28 (UTC)

fakTX fixed it upstream. It compiles just fine now.

GraysonPeddie commented on 2017-03-09 23:28 (UTC)

In the meantime, I'll go with carla-bridges-win. Thanks.

Joermungand commented on 2017-03-09 21:42 (UTC)

It fails here, as well. At first glance, it looks like it might be a JUCE error – which is not uncommon, it’s happened before – but I cannot be entirely sure at this point. I will look into it tomorrow and be back with the results.

GraysonPeddie commented on 2017-03-09 21:16 (UTC)

I'm having problems compiling carla-bridges-wine64-git: ==> Building and installing package ==> Making package: carla-bridges-win64-git 3488.e1e533a5-1 (Thu Mar 9 15:12:54 CST 2017) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Updating carla-bridges-win64-git git repo... Fetching origin -> Found vstsdk366_27_06_2016_build_61.zip ==> Validating source files with md5sums... carla-bridges-win64-git ... Skipped vstsdk366_27_06_2016_build_61.zip ... Passed ==> Extracting sources... -> Creating working copy of Carla git repo... Switched to a new branch 'makepkg' -> Extracting vstsdk366_27_06_2016_build_61.zip with bsdtar ==> Starting pkgver()... ==> Removing existing $pkgdir/ directory... ==> Starting build()... make[1]: Entering directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/jackbridge' make[1]: Nothing to be done for 'win64e'. make[1]: Leaving directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/jackbridge' make[1]: Entering directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/modules/juce_audio_basics' make[1]: Nothing to be done for 'win64'. make[1]: Leaving directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/modules/juce_audio_basics' make[1]: Entering directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/modules/juce_audio_processors' Compiling juce_audio_processors.cpp (64bit) Creating juce_audio_processors.win64.a make[1]: Leaving directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/modules/juce_audio_processors' make[1]: Entering directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/modules/juce_core' make[1]: Nothing to be done for 'win64'. make[1]: Leaving directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/modules/juce_core' make[1]: Entering directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/modules/juce_data_structures' make[1]: Nothing to be done for 'win64'. make[1]: Leaving directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/modules/juce_data_structures' make[1]: Entering directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/modules/juce_events' make[1]: Nothing to be done for 'win64'. make[1]: Leaving directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/modules/juce_events' make[1]: Entering directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/modules/juce_graphics' make[1]: Nothing to be done for 'win64'. make[1]: Leaving directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/modules/juce_graphics' make[1]: Entering directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/modules/juce_gui_basics' Compiling juce_gui_basics.cpp (64bit) In file included from ../juce_core/juce_core.h:236:0, from ../juce_graphics/juce_graphics.h:55, from juce_gui_basics.h:55, from juce_gui_basics.cpp:45: ../juce_core/maths/juce_NormalisableRange.h: In member function ‘ValueType juce::NormalisableRange<ValueType>::convertFrom0to1(ValueType) const’: ../juce_core/maths/juce_NormalisableRange.h:132:13: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if (skew != static_cast<ValueType> (1) && proportion > ValueType()) ^~ ../juce_core/maths/juce_NormalisableRange.h:135:17: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’ return start + (end - start) * proportion; ^~~~~~ In file included from juce_gui_basics.cpp:282:0: native/juce_win32_Windowing.cpp: At global scope: native/juce_win32_Windowing.cpp:745:15: error: explicit specialization in non-namespace scope ‘class juce::UWPUIViewSettings’ template <> ^ native/juce_win32_Windowing.cpp:746:12: error: specialization of ‘template<class Type> struct juce::UUIDGetter’ must appear at namespace scope struct UUIDGetter<IUIViewSettingsInterop> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ native/juce_win32_Windowing.cpp:774:15: error: explicit specialization in non-namespace scope ‘class juce::UWPUIViewSettings’ template <> ^ native/juce_win32_Windowing.cpp:775:12: error: specialization of ‘template<class Type> struct juce::UUIDGetter’ must appear at namespace scope struct UUIDGetter<IUIViewSettings> ^~~~~~~~~~~~~~~~~~~~~~~~~~~ native/juce_win32_Windowing.cpp:786:12: error: too many template-parameter-lists struct ComBaseModule ^~~~~~~~~~~~~ native/juce_win32_Windowing.cpp:803:5: error: ‘ComBaseModule’ does not name a type ComBaseModule comBaseDLL; ^~~~~~~~~~~~~ native/juce_win32_Windowing.cpp: In constructor ‘juce::UWPUIViewSettings::UWPUIViewSettings()’: native/juce_win32_Windowing.cpp:667:9: error: ‘ComBaseModule’ was not declared in this scope ComBaseModule dll (L"api-ms-win-core-winrt-l1-1-0"); ^~~~~~~~~~~~~ native/juce_win32_Windowing.cpp:669:13: error: ‘dll’ was not declared in this scope if (dll.h != nullptr) ^~~ native/juce_win32_Windowing.cpp:681:63: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (status != S_OK && status != S_FALSE && status != 0x80010106L) ~~~~~~~^~~~~~~~~~~~~~ native/juce_win32_Windowing.cpp:698:13: error: ‘comBaseDLL’ was not declared in this scope comBaseDLL = static_cast<ComBaseModule&&> (dll); ^~~~~~~~~~ native/juce_win32_Windowing.cpp:698:38: error: ‘ComBaseModule’ does not name a type comBaseDLL = static_cast<ComBaseModule&&> (dll); ^~~~~~~~~~~~~ native/juce_win32_Windowing.cpp:698:51: error: expected ‘>’ before ‘&&’ token comBaseDLL = static_cast<ComBaseModule&&> (dll); ^~ native/juce_win32_Windowing.cpp:698:51: error: expected ‘(’ before ‘&&’ token native/juce_win32_Windowing.cpp:698:53: error: expected identifier before ‘>’ token comBaseDLL = static_cast<ComBaseModule&&> (dll); ^ native/juce_win32_Windowing.cpp:698:60: error: expected ‘)’ before ‘;’ token comBaseDLL = static_cast<ComBaseModule&&> (dll); ^ make[1]: *** [Makefile:96: ../../../build/juce_gui_basics/Release/juce_gui_basics.cpp.win64.o] Error 1 make[1]: Leaving directory '/tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/source/modules/juce_gui_basics' make: *** [Makefile:134: /tmp/yaourt-tmp-grayson/aur-carla-bridges-win64-git/src/carla-bridges-win64-git/build/modules/Release/juce_gui_basics.win64.a] Error 2

Joermungand commented on 2015-01-14 19:46 (UTC)

PKGBUILD compiles again after thatest commits, so we’re back on track.

Joermungand commented on 2014-11-22 13:35 (UTC)

It seems mingw compilation is currently broken. Please check out ‘carla-bridges-win’ instead, it provides the binaries available on SourceForge. That should do for now.

Joermungand commented on 2014-10-27 19:44 (UTC)

This package depends on Steinberg’s VST3 SDK – without which, it will not build. A copy of it can be retrieved by signing in at http://www.steinberg.net/en/company/developers.html and has to be placed in the same directory as the PKGBUILD. The SDK version referred to in the PKGBUILD is vstsdk360_22_11_2013_build_100.zip, the latest at the time when the file was created. If you get a newer version, you will have to update the file name in the PKGBUILD, as well as its md5sum.