Hi,
As far as I know, no one has ported JavaScriptCore to GNUstep. It might not be
a huge amount of work but that last time I looked at it (ten or so years ago)
the build system for JSC conflated a lot of things in the Apple paths that
would need disentangling if you want the Cocoa bits but
Did you remember to disable incremental linking?
Last time I tested it, LINK.EXE did work, but if you had incremental linking
enabled (I think it’s on by default?) then it inserts random padding into the
Objective-C runtime’s metadata sections, which corrupt various things.
David
> On 18 Jul
On 19/01/2021 12:57, H. Nikolaus Schaller wrote:
Given that this is searching from under a hundred things, all of which can be
downloaded in a single HTTP request quite cheaply, you could do that client
side in less than one network round trip time.
And you can click the "Anything wrong
On 19/01/2021 13:09, H. Nikolaus Schaller wrote:
BTW: I forgot to mention that we already have a GNUstep way of storing all this
metadata:
http://www.gnustep.org/softwareindex/plist.php
The idea behind this is the recently mentioned GAPstore.app which would allow
to show
the same
On 19/01/2021 12:12, H. Nikolaus Schaller wrote:
How would all this work for dynamic content
likehttp://www.gnustep.org/softwareindex/ ?
Can you be a bit more specific? At first glance, that looks pretty
static: There's a top-level index page and a load of child pages. I'd
put each of
Gregory,
On 19/01/2021 12:01, Gregory Casamento wrote:
Mhm AWS...
Not a fan of Amazon :P
Don't care
You floated the idea of a CoC over Christmas and this is the kind of
exchange that makes me think that the project might need one. I
understand that you don't want to derail the
[ Disclaimer: I work for the company that owns GitHub, but these
opinions are my own and not corporate policy ]
On 18/01/2021 23:36, Ivan Vučica wrote:
- Should we turn the index into a set of static pages generated from
MySQL data, which we then check in?
- If we turn each entry into a single
On 05/11/2020 14:54, Gustavo Tavares wrote:
Throwing 0x1677ab8, in flight exception: (nil)
Exception caught by C++: 0
This bit looks as if I accidentally left some debugging code enabled in
the runtime. Did you build the trunk version of libobjc2?
David
On 04/11/2020 18:54, Gregory Casamento wrote:
Just FYI, you still need a display server (whether that's X or Windows
or whatever) to start a headless application. Is this an issue? If it
is, then we would need something like the null backend.
I have worked around this issue in the past by
On 26 Aug 2020, at 17:23, H. Nikolaus Schaller wrote:
>
>>
>> Am 26.08.2020 um 18:11 schrieb Gregory Casamento :
>>
>> I am not sure if David Chisnall ever got libobjc2 working on MIPS.
>
> I also have no idea - I was just assuming that it works if not rejec
On 18/08/2020 02:19, Svetlana Tkachenko wrote:
What OS is the bst equipped to run GNUstep on it with minimal confusion to the
novice user?
FreeBSD. Ships with an Objective-C compiler and a C++ stack that
interoperates well with Objective-C in Objective-C++. Doesn't require
jumping through
Hi,
Having a custom VM seems like a high maintenance way of doing this. For
another project, we're using Azure Pipelines to generate an apt package
repo directly from the CI pipeline. There are pipeline actions for
doing all of the required steps.
I'm already using Azure Pipelines for
On 07/07/2020 20:13, Gregory Casamento wrote:
GNUstep, very much contrary to popular belief, neither maintains the
objc portion of gcc nor does it maintain clang. If you are getting a
segfault while running clang the most expedient place to report any bugs
with clang is on their website.
Hi,
You don’t actually need anything new from the runtime to support this. I
implemented something equivalent in the EtoileFoundation framework around 2007
and GNUstep also has something similar in -Base Additions.
Categories are somewhat problematic in Objective-C because there is no
On 18 Jun 2020, at 11:05, Johannes Brakensiek wrote:
>
> Thank you for your reply, David.
>
> On 18 Jun 2020, at 10:46, David Chisnall wrote:
>
>>> If you want to build libobjc2 on armhf you will have to use the older
>>> version 1.9 of libobjc (which does
> On 15 Jun 2020, at 08:13, Johannes Brakensiek
> wrote:
>
> But afaik some parts of libobjc2 2.0 are built from assembler code. The
> needed code for the armhf architecture does not exist yet. That architecture
> is 32bit. If you try the 64bit variant (aarch64) it should work afaik.
I am
On 12/06/2020 12:07, Andreas Fink wrote:
Does anyone know how I can catch these exceptions in lldb:
Throwing 0x7f2fa8004588, in flight exception: 0x7f2fa8004588
Exception caught by C++: 0
the usual
break set -S raise
I'm not sure what that does. I set breakpoints on __cxa_throw and
Hi,
I'm not sure where you get that from. The only comment about 64-bit on
that page is in reference to Apple's implementation, stating that the
new ABI is the only option on 64-bit Apple platforms (Apple supported
the old and new ABIs on 32-bit x86, only the new one on 64-bit Macs and
only
On 10/06/2020 10:47, Umberto Cerrato wrote:
Hi Patrick,
About Discord?
If you can browse the web you can “have it” :)
If you can browse the web and are willing to agree to Discord's
obnoxious 'privacy' policy then you can have it. I got about half way
down it before deciding that there is
On 10/06/2020 10:42, Patrick Cardona via Discussion list for the GNUstep
programming environment wrote:
Ref : First Steps in GNUstep GUI Programming (2) : NSWindow, NSButton
Edition : First Edition: July 2000; Last Updated: January 2008
URL :
On 25 May 2020, at 06:51, Patryk Laurent wrote:
>
> Indeed— thank you, I saw that discussion, it sounds like this is a libobjc2
> message that needs to be guarded by a debug flag.
FYI: This is now hidden behind an off-by-default CMake flag.
Note: It is still worth fixing most of the places
Hi Andreas,
These warnings are fine to ignore (they should be guarded by debug
builds of libobjc2 or an environment variable, but they aren't
currently). You're seeing them now because Richard found and half fixed
a bug in our detection of when to use the fast paths, and I finished and
On 07/05/2020 05:49, Gregory Casamento wrote:
Hey guys... I'd really like to start development on a (UIKit compatible
or not) backend for Android which will allow the creation of GUI apps.
Ideally what I would like is something that extends UIKit if possible.
Since we are talking about this
On 22/02/2020 03:46, Patryk Laurent wrote:
I believe that there is (or at least was) already dl_iterate_phdr,
and that for some reason this was added to get the list of classes
without actually loading
the object file? If that path still exists, its perhaps possible this
series of issues, is
On 16/02/2020 20:42, Patryk Laurent wrote:
I see the list “frameworkClasses” is meant to be populated during the make
process running “nm *.o -Pg” as part of EXTRACT_CLASS_NAMES_COMMAND. Defined in
target.make, this command is used to look for lines output from nm starting
with
On 13/02/2020 16:51, Richard Frith-Macdonald wrote:
Thanks for that information.
My (limited) understanding of -r is that it's for incremental linking, where
the file produced by the linker can itself be used to be linked into an
executable.
Correct. The v2 ABI depends on a couple of
it.
David
On 13/02/2020 14:31, Gregory Casamento wrote:
An observation. I only see this on subsequent installs. The first
always goes ok.
Another question. How do i switch to ld.gold?
On Thu, Feb 13, 2020, 9:16 AM David Chisnall <mailto:gnus...@theravensnest.org>> wrote:
On 1
On 13/02/2020 10:35, Richard Frith-Macdonald wrote:
Is it a bug in the linker?
It is, but it is a bug that shows up *only* with ld -r. LLD did not
support ld -r for a long time and that made no difference to over 90% of
the things in the FreeBSD ports collection. It is a very rarely used
On 11/02/2020 12:30, Richard Frith-Macdonald wrote:
clang -v reported that the normal, system linker was being used
FYI: On most GNU/Linux platforms, BFD is the 'normal, system linker'.
For example:
$ ld -v
GNU ld (GNU Binutils for Debian) 2.31.1
This is the BFD linker on a Debian system.
ryk Laurent wrote:
>
> Hi,
>
> On December 29, 2019 at 6:21 AM, David Chisnall
> wrote:
>
>> On 29 Dec 2019, at 13:16, Fred Kiefer wrote:
>>>
>>>> 2019-12-29 00:35:39.702 ProjectCenter[10666:10666] NSDocumentClass
>>>> PCProjectDocument
On 06/01/2020 09:30, Riccaro Mottola wrote:
There is a bug in BFD LD. Things that use ld -r in some situations (I
have not been able to find a minimal test case, but base additions is
one) have things stripped too early and so all of the Objective-C
classes are removed.
On my working setup
On 05/01/2020 16:15, Patryk Laurent wrote:
Do you think the bug is also is in ld.gold? During build, we set
LD=/usr/bin/ld.gold (for
example,https://github.com/plaurent/gnustep-build/blob/master/ubuntu-19.10-clang-9.0-runtime-2.0/GNUstep-buildon-ubuntu1910.sh#L46)
Is $LD actually used to
On 2 Jan 2020, at 20:50, Fred Kiefer wrote:
>
> from now on this is a clang issue and I am no longer of any help here. Maybe
> David has an idea what is going on? It would help to know which version of
> clang used to work and on which version it is failing. The next thing would
> be to write
On 29 Dec 2019, at 13:16, Fred Kiefer wrote:
>
>> 2019-12-29 00:35:39.702 ProjectCenter[10666:10666] NSDocumentClass
>> PCProjectDocument not found
Is this project using ld -r (I forget what GNUstep Make calls this -
subprojects?)? If so, it may be the same issue as Base Additions, which
On 29 Dec 2019, at 03:01, Patryk Laurent wrote:
>
> ./Framework/ProjectCenter.framework/./libProjectCenter.so: error: undefined
> reference to '__objc_ivar_offset_NSView._tracking_rects.'
It looks as if PC is using a private NSView ivar. This will need to have to
change to using reflection
On 26 Dec 2019, at 01:32, Patryk Laurent wrote:
>
>
> Hi David,
>
>> On Dec 25, 2019, at 01:19, David Chisnall wrote:
>>
>> Hi,
>>
>> This sounds like the issue with the Linux run-time linker and the 1.x
>> non-fragile ABI. This can be fixe
Hi,
This sounds like the issue with the Linux run-time linker and the 1.x
non-fragile ABI. This can be fixed by either:
1. Using pretty much any non-Linux OS, or
2. Using the 2.0 ABI and clang 8.0 or later.
David
> On 25 Dec 2019, at 04:02, Patryk Laurent wrote:
>
> Hi,
>
> At Gorm
Hi,
The problem that you identify (input and output coordinate spaces are
different) is also a problem with CoreAnimation and with X11's XRENDER
extension: in both you can apply an affine transform to the output, but
input coordinates are not transformed.
This is something that you can work
On 1 Dec 2019, at 10:17, Riccardo Mottola wrote:
>
> Right. Please do not distort things. While I make sure that everything is
> "gcc clean" for my own use, I do test, run and build GNUstep with clang
> almost daily. My main workstation is FreeBSD + Clang + GNUstep. Of course, it
> means I do
On 27 Nov 2019, at 18:29, Ivan Vučica wrote:
>
> I will intentionally not discuss this further, and I have
> intentionally not dug very deep. I don't want to be overly exposed to
> ideas beyond the APIs.
Apple wrote quite a lot publicly about how their fast rendering server (Quartz
On 27/11/2019 08:37, Fred Kiefer wrote:
For me this reoccurring build issues are one of the reasons why I do not use
clang and the new runtime. They both develop too fast for me. It is quite
normal that things change and from time to time they are even broken. If I
remember correctly most of
On 26/11/2019 22:43, Fred Kiefer wrote:
If I understand you correctly your suggestion is that we try to add support in
gcc for some of the basic ObjC 2.0 features. That should be doable although the
last time I tried I gave up on it. That was right after the Dublin meeting
where we had a
On 27/11/2019 10:49, Andreas Fink wrote:
Which cmake version did you use to get it built as the one coming with
Debian10 is too old.
What error did you get? The minimum required is 3.1[1], which is from
some time around 2014. I would be shocked if Debian included something
that old.
On 27/11/2019 00:25, Andreas Fink wrote:
This is now under Debian10 with clang-10 from the llvm repo.
cmake is very cryptic here to tell us where it breaks. so go figure
I never use the makefile generator for CMake, but with ninja you can do
ninja -v to see the build steps (and it
On 25 Nov 2019, at 14:07, H. Nikolaus Schaller wrote:
> I am not sure that this is the only way to implement it.
>
> First of all the callMethodOn returns some block which is a data structure
> knowing that it should take the parameter x and do some function.
> Let's call it NSBlock. NSBlock
On 25 Nov 2019, at 17:07, Andreas Fink wrote:
> (https://en.wikipedia.org/wiki/Debian#Architecture_ports)
>
> As of the Stretch release, the official ports are:[157]
[ snip ]
> • s390x: z/Architecture with 64-bit userland, intended to replace
> s390[160]
> Lets see what clang-10
On 25 Nov 2019, at 15:08, Yavor Doganov wrote:
>
> David Chisnall wrote:
>> On 25 Nov 2019, at 13:37, Yavor Doganov wrote:
>>> RISC-V is the newest GNU/Linux architecture and it's not yet
>>> supported by Clang.
>>
>> Yavor, I appreciate that this is
On 25 Nov 2019, at 13:37, Yavor Doganov wrote:
>
> RISC-V is the newest GNU/Linux architecture and it's not yet supported
> by Clang.
Yavor, I appreciate that this is an emotional topic for you, but please can you
try to confine yourself to the truth? RISC-V is a supported architecture by
tely off here.
>
> Fred
>
>> Am 24.11.2019 um 13:27 schrieb David Chisnall :
>>
>> Hi,
>>
>> I have spent some time looking at this issue. It appears to be an issue in
>> how the GSIMap macros are used in NSConcrete{Hash,Map}Table. This is
On 25 Nov 2019, at 10:18, H. Nikolaus Schaller wrote:
>
> Fred mentioned that it could be possible to define some block wrapper macros
> if some time is invested.
> It that works out, we do not make our decisions depend on gcc *not*
> implementing something.
Fred made this claim, but he also
On 25 Nov 2019, at 09:37, Gregory Casamento wrote:
>
> * C++, while this is not exclusive to clang, gcc doesn't support the latest
> version of C++. Clang is extraordinarily good at optimization.
I don’t think this is true. We have a C++17 project that we test in CI with
GCC. The only
to disable them for this setup?
>
> Fred
>
>> Am 11.11.2019 um 18:36 schrieb David Chisnall :
>>
>>
>> Where do the tests fail currently? These look sufficiently simple that they
>> should just be calling a few of the ARC functions. The implementatio
On 23 Nov 2019, at 14:48, Riccardo Mottola wrote:
>
> Hi,
>
>
> On 11/20/19 12:28 PM, David Chisnall wrote:
>>
>> I'm happy to take contributions for the assembly paths for other
>> architectures. We currently have:
>>
>> - x86-32
>> - x
On 22 Nov 2019, at 05:31, H. Nikolaus Schaller wrote:
>
> And the first thing I turn off in a
> new Xcode project is ARC.
Why? ARC generates smaller code, faster code, and code that is more likely to
be correct. I find it incredibly hard to understand why someone would actively
choose to
On 20 Nov 2019, at 23:13, cobjective wrote:
>
> On 19 Nov 2019, at 13:42, David Chisnall wrote:
>>
>> On 19/11/2019 09:40, Johannes Brakensiek wrote:
>>>> I understand that the initial idea was to attract more users/developers,
>>>> but… It’s not work
> On 20 Nov 2019, at 20:11, Gregory Casamento wrote:
>
> Derek
>
> On Wed, Nov 20, 2019 at 1:44 PM Derek Fawcus
> wrote:
>> On Wed, Nov 20, 2019 at 10:52:36AM +, David Chisnall wrote:
>> > Oh, and with ARC, all of the C++ implementations hav
On 20/11/2019 11:07, Andreas Fink wrote:
is libobjc even supporting all these other platforms?
The GCC runtime is written in pure C and so should work everywhere that
there's a C compiler. The GNUstep runtime uses assembly to implement
two features that can't be implemented in pure C:
On 19/11/2019 23:28, Ivan Vučica wrote:
On Tue, Nov 19, 2019 at 5:26 PM Jordan Schidlowsky
mailto:jor...@noodlecake.com>> wrote:
> Is this not the strongest argument to deprecate GCC, and just build
on Clang/LLVM? If feature parity with Apple's API is the goal, isn't
this kind of a
On 20/11/2019 09:55, Richard Frith-Macdonald wrote:
I have never used a mixed configuration, but from what David's said in the past
(I expect he will correct me if I'm wrong), for the libraries ARC should work
whether or not GNUstep is built with clang.
ARC and non-ARC work well together,
On 19/11/2019 16:17, Liam Proven wrote:
On Tue, 19 Nov 2019 at 15:43, David Chisnall wrote:
Their T are not some that I would ever consider agreeing to, or that
I would ever recommend for any free / open source software project and I
would strongly recommend that anyone considering using
possible but that. I
have to take action but seriously, It is very well made and there are no
alternatives around...
(A little bit like e.g. Facebook...)
Anyway thank you
Il giorno 19 nov 2019, alle ore 15:43, David Chisnall
ha scritto:
Hi,
Interesting timing, Discord just came up
Hi,
Interesting timing, Discord just came up in the context of LLVM
yesterday and ass a result, I read their T and Privacy Policy.
Their T are not some that I would ever consider agreeing to, or that
I would ever recommend for any free / open source software project and I
would strongly
On 18/11/2019 11:31, Gregory Casamento wrote:
Currently I know about the following missing functionality:
* ARC
These three letters hide a huge amount. It isn't just inserting
-retain/-release calls, the requirements for ARC are:
- Add the concept of method families for controlling
On 19/11/2019 09:40, Johannes Brakensiek wrote:
I understand that the initial idea was to attract more
users/developers, but… It’s not working.
Hm, yes. I think developers don’t need a nice UI at first place (and I
think most of what developers need luckily is already provided by Apple
as of
Hi,
Where do the tests fail currently? These look sufficiently simple that
they should just be calling a few of the ARC functions. The
implementation of these classes is in
NSConcrete{PointerFunctions,HashTable}.m and their interaction with the
runtime is defined here:
Hi,
There are a few different representations of numbers in the small object
representation. On 32-bit platforms, there is only small int, which has
the low bit set to 1 and stores a 32-bit integer in the remaining bits.
On 64-bit platforms, the low 3 bits indicate the type, with the
On 04/11/2019 18:36, Jordan Schidlowsky wrote:
If people are really concerned about the bug/issue tracking being tied
to github's platform, then just do in-repository tracking. Pretty
simple. If you wanna take advantage of the GitHub platform for pull
requests and issue tracking then do it.
On 04/11/2019 10:26, Umberto Cerrato wrote:
Why don’t you self host your project in your own website? Something like a self
hosted Savannah or similar (there are few around). Then you could: modify the
UI to make it more GitHub-like and user friendly and leave some landing
projects on GitHub,
On 04/11/2019 08:29, Fred Kiefer wrote:
Sorry, I have to disagree on this point. I was present in the Dublin meeting
where we discussed the migration to GitHub and we explicitly decided to leave
the bug tracking on savannah. There should be even some results from this
meeting where these
On 04/11/2019 06:07, Svetlana Tkachenko wrote:
I think clang-8 is in backports.
Is that better than the external repository, or it does not matter?
I'm not sure what is considered best practice for Debian users, but the
LLVM APT repo is officially maintained and I've read a lot of install
On 15/10/2019 09:24, Johannes Brakensiek wrote:
Thank you for that hint. I searched through the GWorkspace makefiles for
„protocol“ and „runtime_version“ but did not find any compiler setting
concerning that. Maybe anyone having more insights into the make process
could help here.
The flag
I'm not sure if it's the same problem, but I've had some issues in CI
that I can't reproduce locally for gworkspace FreeBSD packages. Either
the core or the gworkspace extras appears not to be passing the correct
runtime flags to the compiler, so I get an error when they are linked.
David
Last time I checked:
KVO worked. There is a cleaner way of implementing it on the GNUstep
runtime (which WinObjC does, but GNUstep doesn't yet).
Some of the bindings work, but several of the NS*Controller classes are
missing functionality. Apple is quietly trying to forget Cocoa bindings
structures for registering things with the
runtime. As such, by default, the linker will ignore it.
David
On 07/08/2019 16:07, Frederik Seiffert wrote:
Perfect, thanks – that does the trick.
Frederik
Am 07.08.2019 um 12:29 schrieb David Chisnall :
Have you trued using --whole-archive
Have you trued using --whole-archive?
David
On 07/08/2019 11:18, Frederik Seiffert wrote:
Hi all,
We have ObjC categories that are built into a static library, but these
categories do not get linked into the final executable.
We tried the following linker options without any success:
On 30/07/2019 09:17, David Chisnall wrote:
As I commented on the issue, I believe that one is caused by having too
many hash collisions and the table being unable to resize. I plan at
some point to replace the hash table implementation, which should fix
that issue.
If anyone has a test case
GCC doesn't support __has_attribute. In one of the headers there should
be something like this:
#ifndef __has_attribute
#define __has_attribute(x)
#endif
This header is apparently not being included in NSObjCRuntime.h - I
guess no one has tried building PictureFrame with gcc and a recent
On 30/07/2019 09:12, Frederik Seiffert wrote:
Thanks for the suggestion Jordan. That’s certainly concerning to hear
about the segfaults you’re experiencing with weak references. Is this on
ARMv7 only and do you think it could be related to the WeakReferences
test failing
Hi,
On 01/07/2019 15:38, Frederik Seiffert wrote:
Thanks for the explanation David.
I believe there was a bug in clang where I didn't add an empty symbol
for compilation units that didn't contain any selectors. If you then
linked a program or a library that didn't contain any selectors
On 01/07/2019 13:14, Frederik Seiffert wrote:
1. When using Qt to build a simple test app with Objective C, I’m
getting the following runtime error when launching the app:
java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol
"__start___objc_selectors" referenced by
GNUstep in general is very slow at scrolling. There are various
optimisations that made a huge performance improvement on '90s hardware
and make things a lot slower now.
GNUstep's text rendering also leaves something to be desired. It uses
the Cairo 'toy' interface, which is intended for
On 18/06/2019 16:20, Andreas Höschler wrote:
I wonder why I haven’t found that. Thanks!
struct objc_method_description methodDesc =
protocol_getMethodDescription(_protocol, aSelector, YES, YES);
types = methodDesc.types;
This works great as long as I build with -m32.
On 18 Jun 2019, at 13:47, Andreas Höschler wrote:
>
> Hi David,
>
>> - descriptionForInstanceMethod: is gone. Don't use it, use the runtime
>> functions instead.
>
> Thanks for the hint.
>
> Where would I find a list (the declaration) of these runtime functions on
> MacOSX and GNUstep?
Wow, this is really old code!
On 18/06/2019 12:59, Andreas Höschler wrote:
*SRProxy.m:419:29: **warning: **instance method
'-descriptionForInstanceMethod:' not found (return type defaults to
'id') [-Wobjc-method-access]*
types = [_protocol
When you build in Poudriere, it will install all of the dependencies
that you specified as build dependencies in the jail, then build. If
you missed a build dependency, it will then be caught and so it won't
bite anyone else (or the package builders). It sounds as if you missed
a depencency
On 7 Jun 2019, at 18:27, Riccardo Mottola wrote:
>
> Hi,
>
>
> David Chisnall wrote:
>> It looks as if this protocol comes from NSDistributedNotificationCenter and
>> is created with an @protocol directive. With the gnustep-1.
On 05/06/2019 15:30, Riccardo Mottola wrote:
Hi David!
David Chisnall wrote:
Can you do a backtrace of where the crash is? What is the protocol
that it's inspecting while crashing?
of course... here it is:
Thanks.
Program received signal SIGABRT, Aborted.
0x0008028ca47a
On 05/06/2019 05:30, Riccardo Mottola wrote:
Hi,
David Chisnall wrote:
On 04/06/2019 09:46, Riccardo Mottola wrote:
Hi David,
David Chisnall wrote:
Thanks for the report. Please can you file an issue on GitHub? This
is a quite surprising error - it implies that either clang has a bug
On 04/06/2019 09:46, Riccardo Mottola wrote:
Hi David,
David Chisnall wrote:
Thanks for the report. Please can you file an issue on GitHub? This
is a quite surprising error - it implies that either clang has a bug
or that something is trying to manually create or modify protocols
without
On 04/06/2019 04:14, Riccardo Mottola wrote:
Hi,
I just upgraded all binary packages on FreeBSD using clang and packaged
libobjc2:
11.2-RELEASE-p10 FreeBSD 11.2-RELEASE-p10 #0: Mon May 13 21:20:50 UTC 2019
installed libobjc2 is:
libobjc2-2.0_1 Replacement Objective-C runtime
ackage
[00:02:04] Cleaning up
[00:02:04] Unmounting file systems
If you're still not bored to death by this endless series of
problems, any clues on how to solve this are appreciated.
Kind regards,
Op ma 27 mei 2019 om 19:06 schreef David Chisnall
mailto:gnus
On 27 May 2019, at 12:07, Edwin Ancaer wrote:
>
> The one haunting me now is the fact that I have to run the poudriere command
> to test my port for renaissance as root and that for root, the GNUStep
> environment is not defined.
>
You have to run poudriere as root, but then it will source
On 23 May 2019, at 23:20, Edwin Ancaer wrote:
>
> Is this the linker problem David mentioned earlier, or is this something that
> can be solved by changing the code?
>
Can you try setting LLD_UNSAFE (I think that’s the flag) in the port Makefile?
There are a few Objective-C things that
Hi,
I'd not looked at the Swift corelibs version of libdispatch. Looking at
its headers, there are some feature test macros that check if you have
Objective-C support, which seem to only enable Objective-C interop on
Apple platforms:
, apparently.
Thanks,
Op wo 22 mei 2019 om 10:37 schreef David Chisnall
mailto:thera...@theravensnest.org>>:
On 21/05/2019 20:32, Fred Kiefer wrote:
> That would be 2009, ten years ago, yes this could fit to the
errors you are getting. In part this is our problem as no
On 21/05/2019 20:32, Fred Kiefer wrote:
That would be 2009, ten years ago, yes this could fit to the errors you are
getting. In part this is our problem as no release was done in the time in
between. Still could you please switch to the master branch and only report
issues for that branch?
way to do this. practcally. Also, a warning, I'm just 'Joe
the programmer', I have no computer science degree nor exceptional
programming skills, so I might get stuck when things become more complex.
Kind regards,
Op di 21 mei 2019 om 10:13 schreef David Chisnall
mailto:gnus
Ooops, hit sent too soon:
On 21/05/2019 08:26, Edwin Ancaer wrote:
In file included from ../EOControl/EOQualifier.h:36:
../EOControl/EOKeyValueArchiver.h:84:3: error: unknown type name
'NSMutableArray'
NSMutableArray *_allUnarchivedObjects;
^
It looks as if EOKeyBalueArchiver.h is
Hi,
I'd strongly recommend that you only ever build ports using Poudriere.
The makeplist target doesn't work reliably, but if you build with
poudriere testport then it will tell you all of the things that are
wrong in the plist and you can just copy and paste them to construct the
pkg-plist
I don’t think they’re there, but I’m happy to commit a port if you want to
maintain one. Last time I tried it (admittedly, around 15 years ago), it
worked out of the box on FreeBSD, so it should just be a few lines of Makefile
and a pkg-descr / pkg-plist.
That said, there’s something broken
1 - 100 of 1213 matches
Mail list logo
