Hi Alan,
On Thu, Apr 25, 2013 at 7:42 AM, Alan Coopersmith
<alan.coopersm...@oracle.com> wrote:
> On 04/24/13 10:28 PM, Geert Uytterhoeven wrote:
>> On Thu, Apr 25, 2013 at 7:23 AM, Alan Coopersmith
>> <alan.coopersm...@oracle.com> wrote:
>>> On 04/24/13 10:00 PM, Keith Packard wrote:
>>>> Alan Coopersmith <alan.coopersm...@oracle.com> writes:
>>>>> On 04/24/13 06:58 PM, Keith Packard wrote:
>>>>>> Alan Coopersmith <alan.coopersm...@oracle.com> writes:
>>>>>>> This broke my build:
>>>>>>>
>>>>>>> Undefined first referenced
>>>>>>> symbol in file
>>>>>>> c2p_unsupported
>>>>>>> ../../../miext/shadow/.libs/libshadow.a(shafb4.o)
>>>>>>
>>>>>> Builds fine with GCC; perhaps that figures out that this function can
>>>>>> never be called?
>>>>>
>>>>> If I build with gcc 4.7.2 with -O2 it indeed optimizes it out.
>>>>> If I build with gcc 4.7.2 with -g and no -O flags, it fails the same
>>>>> way.
>>
>> Sorry, I forgot that unlike Linux kernel people, xorg people sometimes
>> do compile
>> without optimization.
>
> Or in the case I first hit this, with optimization using compilers that
> aren't gcc. (Xorg is built on several non-Linux platforms, with compilers
> such as clang or Solaris Studio.)
Right.
>>>> That makes sense at least. We could either make c2p_unsupported call
>>>> FatalError or just be a no-op. Any preference?
>>>
>>> I'd prefer at least a BUG_WARN() over a no-op, to give us a hint why
>>> stuff isn't working, though FatalError() also works for something that
>>> should be impossible to hit.
>>
>>
>> Or assert(), or <insert xorg favorite runtime check method here>.
>>
>> This should be indeed impossible to hit, as all calls to the c2p functions
>> use hardcoded parameters.
>>
>> I'm just a bit afraid that adding real error handling will slow down the
>> code.
>> Can it be dependent on DEBUG or so?
>
> Does it matter if the compiler optimizes out the call to c2p_unsupported?
> The performance should be the same for you.
Indeed, I forgot about that (just grabbing my morning coffee).
> Or does this code even need to be built for non-68k platforms at all?
No. I don't think Xfbdev already limits some options to certain platforms?
> (I'm still confused why we just took a big chunk of code for a platform
> with no active maintainer, but if Keith's willing to maintain it himself,
> that's his call. I do hope we can fix the license before release to be
> a standard license, not yet another one-off we all have to add to our
> packages to comply with the terms of.)
I'm open for license changes. What's the recommended one?
But e.g. shiplan2p8.c was based on shpacked.c, so I mimicked its license
on shpacked.c, and refered to that file.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/camuhmdvmro4ogxmpvk-arvtl8po8knrymhbf1p+pklbxwax...@mail.gmail.com
