Re: Another clang problem

From: Garrett Cooper <gcooper_at_FreeBSD.org>
Date: Sun, 3 Oct 2010 13:30:03 -0700
On Sun, Oct 3, 2010 at 12:50 PM, Roman Divacky <rdivacky_at_freebsd.org> wrote:
> On Sun, Oct 03, 2010 at 05:21:15PM +0200, Dimitry Andric wrote:
>> On 2010-10-03 15:41, Derek Tattersall wrote:
>> >In updating gnash to 8.8 the build failed while linking with libvgl.so.  My
>> >current system was built last week, with both kernel and world built
>> >with clang.  The linkage failure was due to an inlined function,
>> >"set4pixels" which is only referred to, as far as I can tell, within the
>> >source file simple.c which contains the function definition.
>>
>> The problem is that set4pixels() and another function set2lines() are
>> defined as 'inline' functions in simple.c, but it is compiled with
>> -std=gnu99.  This means that these definitions cannot be called from
>> another object file.
>>
>> So, either libvgl should be compiled with -std=gnu89, or somebody who
>> knows about libvgl's "official" API should decide whether these
>> functions must be externally accessible or not.  Since libvgl looks very
>> old (it was imported 8 years ago, and the last functional change was 6
>> years ago), the former is probably the easiest fix.
>
> we compile world with -std=gnu99 even with gcc, why isnt this problem
> with gcc?

    Has someone tried compiling with clang and c99, as opposed to
gnu99? I'm curious as to whether or not the c99 implementation with
clang is always correct, and if that works, whether or not the gnu99
implementation on gcc has a subtlety that isn't implemented properly
on clang.
Thanks,
-Garrett
Received on Sun Oct 03 2010 - 18:30:05 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:08 UTC