I never needed something like what you wrote. That stuff belongs in a
framework. If a compiler doesn't support an attribute that I need (and I
typically don't need attributes), then I don't support the compiler.
Objective-C modules also doesn't really need anything special to expose C
functions
This piece of code is from SubtitleKit, a library regarding processing
different types of subtitle files. I occasionally use some features that does
not exist in GCC or older versions of Clang so I used those boilerplates to
make sure my code compiles under all my target platforms with minimal c
On 14 Jun 2013, at 02:54, Frank Rehwinkel wrote:
> libmap.conf is cool. But in this case, maybe I can't get away with using it.
>
> An obj-c program I wrote that uses all the ..so libraries we've talked about
> didn't run when I mapped the libsupc++.so I found from a stable/9.1 ftp site.
>
I will give you my settings once I got home (use libsupc++.a under 64-bit
Ubuntu 13.04). However my settings is calling for LLVMgold.so and
clang+binutils LTO support.
Sent from my iPhone
> On 2013年6月14日, at 17:48, David Chisnall wrote:
>
>
>> On 14 Jun 2013, at 02:54, Frank Rehwinkel wrote
On 14 Jun 2013, at 12:31, Maxthon Chan wrote:
> I will give you my settings once I got home (use libsupc++.a under 64-bit
> Ubuntu 13.04). However my settings is calling for LLVMgold.so and
> clang+binutils LTO support.
Have you tested that this actually works? Even if you do somehow manage t
Do you guys use LTO? I find its performance boost impressive. When I am
bootstrapping clang, I compared performance of clang built with gcc (-O3, no
LTO, but gcc have a better optimizer) and LLVM LTO (-O3 -flto, but LLVM
optimizer is less aggressive than gcc's) and it gave my clang a 50%~100%
p
I get the same link errors when I build libobjc against libsupc++ copied
from stable/9.1 and from current/10.0. Just to be clear, I didn't build a
new system, I just ftp'ed the base tarballs from a FreeBSD ftp site.
I could not find a source for a stable/9.0 base tarball.
-Frank
On Fri, Jun 14
The GNUstep-base make check for NSTimeZone's +timeZoneWithName: is based on
an invalid assumption.
As a result, it fails on my FreeBSD 9.1 system (and could give the
impression that the class has a bug in it).
The test is meant to check whether an NSTimeZone can be built from a
timezone name. Tur
I've been through this with Java applications - had a customer setting time
zone to 'GB' and all sorts of things were breaking with third-party Java
components distributed with our app. Turns out it isn't an official Olsen time
zone abbreviation nor is it a POSIX one - just a locally traditional
