Package Base Details: darling-git

Git Clone URL: (read-only, click to copy)
Keywords: Darwin Emulator macOS OSX Wine
Submitter: Xorg
Maintainer: jamesbrink
Last Packager: jamesbrink
Votes: 34
Popularity: 0.125861
First Submitted: 2013-06-29 15:19
Last Updated: 2019-07-23 02:37

Pinned Comments

jamesbrink commented on 2019-07-10 02:27

Please use this package for stable more reliable builds

This one is identical but locked in on a last known working git ref and I will update as often as I can.

I have also raised an issue about versioning so maybe we can get some kind of tags for future versions and stable working builds

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 ... Next › Last »

AndrewGura commented on 2016-12-17 11:33

@Xorg thanks for your response! I've actually clonned latest revision 6d5dd2786681c6712f340c4f9fd2af578ed4f974 from 4 December 2016

Xorg commented on 2016-12-17 09:26

@AndrewGura: Actually, the Darling development focuses on Security framework, and I think it is a bug introduced not long ago.
What is your Darling revision (e.g. commit number)?

AndrewGura commented on 2016-12-17 00:08

Hello @Xorg! I am using latest arch linux x86_64. I'm always get this error while building it:

/tmp/yaourt-tmp-andy/aur-darling-git/src/darling/src/external/security/OSX/libsecurity_apple_csp/lib/MD2Object.cpp:57:22: error: return type of out-of-line definition of
'MD2Object::digestSizeInBytes' differs from that in the declaration
CSSM_SIZE MD2Object::digestSizeInBytes() const
~~~~~~~~~ ^
/tmp/yaourt-tmp-andy/aur-darling-git/src/darling/src/external/security/OSX/libsecurity_apple_csp/lib/MD2Object.h:41:17: note: previous declaration is here
virtual size_t digestSizeInBytes() const;
~~~~~~ ^
1 error generated.
make[2]: *** [src/external/security/OSX/libsecurity_apple_csp/CMakeFiles/security_apple_csp.dir/build.make:807: src/external/security/OSX/libsecurity_apple_csp/CMakeFiles/security_apple_csp.dir/lib/MD2Object.o] Помилка 1
make[1]: *** [CMakeFiles/Makefile2:16197: src/external/security/OSX/libsecurity_apple_csp/CMakeFiles/security_apple_csp.dir/all] Помилка 2
make: *** [Makefile:150: all] Помилка 2

I tried to fix it by myself, but there are a lot of dependencies and I believe it should work properly without that manipulations... What I'm doing wrong?

Xorg commented on 2016-12-04 12:09

Due to Arch doesn't use /usr/libexec, I have modified this path. The new prefix path is /usr/share/darling/prefix (/usr/libexec/darling previously).
Tell me if you are occurring troubles (tested on my comptuer, seems not).

Xorg commented on 2016-11-16 13:02

darling-mach-git doesn't exist anymore. Please use darling-mach-dkms-git instead.

darling-mach-dkms-git offers DKMS support for all kernels with headers installed, and it doesn't depend upon a kernel.

Xorg commented on 2016-11-15 06:20

@J5lx: That's ok. What I want to mean is darling-mach-git package is not a good idea (it doesn't rebuild darling-mach on kernel update), and only darling-mach-dkms-git package is useful. :)

J5lx commented on 2016-11-11 21:03

Um, I just read my own comment again and I realised that it sounds much more offensive than I thought it would when I wrote it. So please don't let that alone be the reason for dropping the package. Even if your solution was in fact suboptimal, I don't see a truly "perfect" solution to this dependency issue myself, and I'm at fault for losing my respect without even noticing. I'm sorry for that, and I thank you for addressing my point despite my rudeness.

Xorg commented on 2016-11-11 12:17

@J5lx: Please keep calm. Ok, dependencies detection for darling-mach-git package is buggy. I think I'll drop this package. Makedepends upon kernel headers has been removed to solve your issue.

See darling-mach-dkms-git package for DKMS version.

J5lx commented on 2016-11-07 21:33

The kernel package detection is bugged:

==> Making package: darling-mach-git r23.44cf244-1 (Mon Nov 7 21:58:36 CET 2016)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Missing dependencies:
-> linux-rt-docs-headers
==> ERROR: Could not resolve all dependencies.

Besides, I believe that setting dependencies dynamically is an utterly stupid idea. Let's suppose I wanted to distribute this as a binary package from my own repository: Now everyone who wanted to install this package from my repo would have to install the rt kernel headers as well, even if they aren't using the rt kernel at all, just because I used it when I built the package. Instead, it would be better to provide the readily-built modules only for the mainline kernel and simply leave the rest to DKMS IMO. That's how kernel module packages from the official repositories do it (See virtualbox-*-modules-arch for instance).

Anonymous comment on 2016-09-24 14:59

Downgrading binutils to 2.26.1 fixed it.