On 16 Jul 2013, at 22:13, Riccardo Mottola wrote:
> Clang 3.1 is also standard for FreeBSD 9.1, although ports provide a more
> current clang.
9.2 was just branched, so 9.1 will go EOL soon. For the FreeBSD ports, I'm
adding a minimum version dependency on clang 3.3. The current WIP ports ch
Hi (David),
when configuring gnustep-base on FreeBSD 9.1 in conjunction with clang33 and
libobjc2 r36872, it's currently broken (since July, 8th):
CC=/usr/local/bin/clang33
CXX=/usr/local/bin/clang++33
$ ./configure --disable-mixedabi CC=${CC} CXX=${CXX}
[…]
checking whether objc really works.
Hi Marcus,
On 17 Jul 2013, at 09:53, Marcus Müller wrote:
> Hi (David),
>
> when configuring gnustep-base on FreeBSD 9.1 in conjunction with clang33 and
> libobjc2 r36872, it's currently broken (since July, 8th):
>
> CC=/usr/local/bin/clang33
> CXX=/usr/local/bin/clang++33
>
> $ ./configure
On 17.07.2013, at 11:02, David Chisnall wrote:
> Can you check your conflg.log to see what it says about the failing program?
Unfortunately, not that much (I've stripped some parts)
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #de
On 17 Jul 2013, at 10:09, Marcus Müller wrote:
> configure:13329: result: no
> configure:13344: error: Your compiler does not appear to implement the
> -fconstant-string-class option needed for support of strings. Please check
> for a more recent version or consider using --enable-nxconstantst
Wasn't this same error also recently reported by Gregory's CI system?
Regards,
Ivan Vučica
via phone
On 17. 7. 2013., at 11:11, David Chisnall wrote:
> On 17 Jul 2013, at 10:09, Marcus Müller wrote:
>
>> configure:13329: result: no
>> configure:13344: error: Your compiler does not appear to
On 17.07.2013, at 11:11, David Chisnall wrote:
> On 17 Jul 2013, at 10:09, Marcus Müller wrote:
>
>> configure:13329: result: no
>> configure:13344: error: Your compiler does not appear to implement the
>> -fconstant-string-class option needed for support of strings. Please check
>> for a m
On 17 Jul 2013, at 10:25, Marcus Müller wrote:
> It seems r36851 breaks gnustep-base's configure somehow.
Hmm, this is the change that ensures that ivars are correctly aligned. I don't
see how it would cause problems of this nature, it should have basically no
effect on the kind of program in
On 17.07.2013, at 11:56, David Chisnall wrote:
> On 17 Jul 2013, at 10:25, Marcus Müller wrote:
>
>> It seems r36851 breaks gnustep-base's configure somehow.
>
> Hmm, this is the change that ensures that ivars are correctly aligned. I
> don't see how it would cause problems of this nature,
Latest Android NDK (8e, from March 2013) contains Clang 3.1:
http://developer.android.com/tools/sdk/ndk/index.html [2]
Considering that it's hard enough to compile for Android (I didn't do
it yet, hopefully I'll get around to it these daysâ¦) I suggest we
target Clang 3.1 for now.--
Ivan VuÄic
On Wed, Jul 17, 2013 at 2:28 PM, Luboš Doležel wrote:
>
> Do your plans to work on UIKit still hold? :-)
>
Long term - I think so :-)
At the moment, I'm 'playing' with the opal backend.
If so, then I'd try to find some time to support the arm target in Darling
> dyld and libobjcdarwin (to sup
Hi Doug,
On Wed, Jul 17, 2013 at 4:42 PM, Doug Warren wrote:
> I'm running gnustep-corebase and gnustep-base on Android based somewhat on
> your patches and somewhat on my own work. Porting a rather large iOS app
> at the moment and writing GTest cases for where I run into problem between
> the
I'm running gnustep-corebase and gnustep-base on Android based somewhat on
your patches and somewhat on my own work. Porting a rather large iOS app
at the moment and writing GTest cases for where I run into problem between
the runtimes. I'll be starting some new threads on at least two of those a
Hi Greg,
There were several things we tried to do:
- make a clearly defined set of image names (listed in
Headers/Additions/GNUstepGUI/GSTheme.h ) for themes to override. Currently we
just have GSSwitch and GSRadio listed there.
- make the image names for themes to override describe what the
Hi,
I can no longer build the latest GNUStep. During the configure step for
core/base I get the following:
checking if the compiler supports -fconstant-string-class... no
configure: error: Your compiler does not appear to implement the
-fconstant-string-class option needed for support of strings.
Hi,
Eric Wasylishen wrote:
Hi Greg,
There were several things we tried to do:
- make a clearly defined set of image names (listed
in Headers/Additions/GNUstepGUI/GSTheme.h ) for themes to override.
Currently we just have GSSwitch and GSRadio listed there.
- make the image names for themes
I'm looking at an odd bug where very simple synchronize tests crash IE:
@interface TestSync : NSObject
@property(nonatomic, retain) NSString* sync;
- (BOOL) doSync;
@end
@implementation TestSync
@synthesize sync;
- (BOOL) doSync
{
@synchronized(sync)
{
BOOL bTest = YES;
return bTest;
}
}
@end
Creating Gorm.app/Resources/Info-gnustep.plist...
plmerge: Uncaught exception (null), reason: -initWithBytes:lenth:encoding
given nul bytes
Aborted
make[2]: [Gorm.app/Resources/Info-gnustep.plist] Error 134 (ignored)
Creating Gorm.app/Resources/Gorm.desktop...
pl2link: Uncaught exception (null),
On 2013-07-17 17:19:13 -0600 Riccardo Mottola
wrote:
>
>> The change that breaks existing themes is that the images now have to be
>> listed in the theme's plist in a GSThemeImages dictionary. Perhaps
>> requiring this is not the way to go.
>>
> I actually found that working without a diction
clang is surprisingly fast if built with LLVM link-time optimisation - even
faster than GCC, from my experience. So I am setting up a new server with this
LTO’d clang. But then I get a SIGSEGV when testing libobjc2 built with this
augment clang. Can anyone test and tell me the reason why?
Build
20 matches
Mail list logo
