Compilation (version 2631.03f5746-1) fails for me. Not sure if the package or the Carla repo is at fault.
make[1]: Entering directory '/home/chris/tmp/yaourt-tmp-chris/aur-carla-bridges-win32-git/src/carla-bridges-win32-git/source/modules/juce_data_structures'
Compiling juce_data_structures.cpp (32bit)
In file included from juce_core.cpp:132:0:
files/juce_File.cpp: In member function 'bool juce::File::createSymbolicLink(const juce::File&, bool) const':
files/juce_File.cpp:917:48: error: 'SYMBOLIC_LINK_FLAG_DIRECTORY' was not declared in this scope
isDirectory() ? SYMBOLIC_LINK_FLAG_DIRECTORY : 0) != FALSE;
^
files/juce_File.cpp:917:80: error: 'CreateSymbolicLink' was not declared in this scope
isDirectory() ? SYMBOLIC_LINK_FLAG_DIRECTORY : 0) != FALSE;
^
In file included from juce_core.cpp:210:0:
native/juce_win32_Files.cpp: In member function 'juce::File juce::File::getLinkedTarget() const':
native/juce_win32_Files.cpp:653:34: error: '::GetFinalPathNameByHandleW' has not been declared
DWORD requiredSize = ::GetFinalPathNameByHandleW (h, nullptr, 0, FILE_NAME_NORMALIZED);
^
native/juce_win32_Files.cpp:660:32: error: '::GetFinalPathNameByHandleW' has not been declared
requiredSize = ::GetFinalPathNameByHandleW (h, buffer, requiredSize, FILE_NAME_NORMALIZED);
^
Makefile:85: recipe for target '../../../build/juce_core/Release/juce_core.cpp.win32.o' failed
make[1]: *** [../../../build/juce_core/Release/juce_core.cpp.win32.o] Error 1
Search Criteria
Package Details: carla-bridges-win32-git 6278.975821819-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/carla-bridges-win32-git.git (read-only, click to copy) |
---|---|
Package Base: | carla-bridges-win32-git |
Description: | Carla win32 bridge |
Upstream URL: | http://kxstudio.sf.net/carla |
Licenses: | GPL2 |
Conflicts: | carla-bridges-win32 |
Provides: | carla-bridges-win32 |
Submitter: | Joermungand |
Maintainer: | Joermungand |
Last Packager: | Joermungand |
Votes: | 8 |
Popularity: | 0.000000 |
First Submitted: | 2014-10-26 21:15 (UTC) |
Last Updated: | 2022-03-16 08:37 (UTC) |
Dependencies (8)
- carla-gitAUR
- mingw-w64-crt (llvm-mingw-w64-toolchain-ucrt-binAUR, llvm-mingw-w64-toolchain-msvcrt-binAUR)
- mingw-w64-pkg-configAUR (llvm-mingw-w64-pkg-configAUR)
- mingw-w64-winpthreads (mingw-w64-winpthreads-gitAUR, llvm-mingw-w64-toolchain-ucrt-binAUR, llvm-mingw-w64-toolchain-msvcrt-binAUR)
- wine (wine-valveAUR, wine-stable-nextAUR, wine-stableAUR, wine-wow64-gitAUR, wine-staging-wow64-gitAUR, wine-ge-customAUR, wine-gitAUR, wine-staging-gitAUR, wine-cachyosAUR, wine-tkg-staging-wow64-binAUR, wine-staging-wow64AUR, wine-wow64AUR, wine-staging)
- gcc-multilib (gcc-gitAUR, gcc-libs-gitAUR, gcc-fortran-gitAUR, gcc-objc-gitAUR, gcc-ada-gitAUR, gcc-go-gitAUR, gccrs-gitAUR, gccrs-libs-gitAUR, gcc-snapshotAUR, gcc) (make)
- git (git-gitAUR, git-glAUR) (make)
- mingw-w64-gcc (mingw-w64-gcc132AUR, llvm-mingw-w64-toolchain-ucrt-binAUR, llvm-mingw-w64-toolchain-msvcrt-binAUR) (make)
Required by (0)
Sources (1)
Latest Comments
« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 Next › Last »
SpotlightKid commented on 2015-11-19 11:51 (UTC)
falkTX commented on 2015-10-11 20:54 (UTC)
the issue with 32bit bridges on 64bit systems has been fixed in carla-standalone.
testing is welcome.
don't forget to rebuild both carla and the bridges.
btw, 32bit jack clients still only cause xruns, but that's a bug for another package.
superprick commented on 2015-05-10 01:03 (UTC)
A little more info. All 32bit windows apps trying to access jack do not work and send xruns climbing hundreds per second. Recently tried reaper 32 bit with wineasio. as soon as a track is opened it happens. However the 64 bit version of reaper is fine. so its either a wine problem or a jack problem. Using jackd2 on both arch and ubuntu 15 produces same results
Joermungand commented on 2015-04-25 17:17 (UTC)
Thanx, falkTX, got it. I’m still investigating the 32-bit win VST issue. Will make a resolution once that reaches any conclusive result.
falkTX commented on 2015-04-25 17:06 (UTC)
you need to use "make HAVE_LIBLO=false" so it properly skips the liblo check.
Joermungand commented on 2015-04-25 15:04 (UTC)
SpotlightKid, nothing’s wrong with the compilation flags. You need to install mingw-w64-liblo, available here: https://aur.archlinux.org/packages/mingw-w64-liblo . I removed it as a dependency, since it was no longer needed – yet apparently it is required as a build-dep. I’m not updating the PKGBUILD, yet, as I’m first trying to find out what’s wrong with the 32 bridges (not currently working).
superprick commented on 2015-04-19 11:19 (UTC)
yes both locally built and source forge binaries. Joermungand reported the same issue. I will go one step more to report that it does the same in Vanilla Ubuntu 15.04 beta 2 and ubuntu studio 15.04 beta 2. On the same machine it works fine on ubuntu 14.04. This would lead me to believe that new libraries or packages upstream are are causing the problem. something to look into as you will probably recieve more reports as the new ubuntu is releaseed.
falkTX commented on 2015-04-19 10:33 (UTC)
You mean you used the binaries linked from the kxstudio webpage and it still gives the same error?
Because if it that's the case then this has nothing to do with my side. The 2.0-beta4 binaries were known to work at some point and have not changed.
superprick commented on 2015-04-19 03:59 (UTC)
Faltx have you been able to reproduce the issue that Joermengand and i have experienced. I downgraded my wine all the way back to 1.6.... same issue. both SF binaries and My own Build.
SpotlightKid commented on 2015-04-18 15:51 (UTC)
I get the following error while compiling:
Compiling CarlaEngineOscSend.cpp (win32 bridge)
In file included from ../backend/engine/CarlaEngineOsc.hpp:26:0,
from ../backend/engine/CarlaEngineInternal.hpp:21,
from ../backend/engine/CarlaEngine.cpp:26:
../utils/CarlaOscUtils.hpp:23:19: fatal error: lo/lo.h: No such file or directory
#include <lo/lo.h>
^
compilation terminated.
Makefile:339: recipe for target '../../build/bridges-plugin/Release/CarlaEngine.cpp.win32.o' failed
/usr/include/lo/lo.h is present, so something must be wrong with the compilation flags.
Pinned Comments