[SDL] SDL2 (latest hg, as of this morning) error in my application

Sam Lantinga slouken at libsdl.org
Fri Mar 15 13:42:11 PDT 2013


No problem! :)

On Fri, Mar 15, 2013 at 1:09 PM, Alex Barry <alex.barry at gmail.com> wrote:

> No worries mate, I also saw that buildbot was bunged up, so I figured you
> wouldn't have caught it.  Again, thanks to both of you for the quick fix :)
>
> On Fri, Mar 15, 2013 at 4:02 PM, Ryan C. Gordon <icculus at icculus.org>wrote:
>
>>
>> Whoops, buildbot is hung up, so it never tested if this was broken; sorry!
>>
>> --ryan.
>>
>>
>> On Mar 15, 2013, at 2:51 PM, Alex Barry <alex.barry at gmail.com> wrote:
>>
>> I noticed a lot of people were just having to install a pile of 32-bit
>> libraries to make SDL work properly, so I decided to switch to Ubuntu
>> 32-bit...now I have a different problem:
>>
>> /bin/bash ../build-scripts/updaterev.sh
>>> /bin/bash ./libtool --mode=compile gcc -g -O3 -DUSING_GENERATED_CONFIG_H
>>> -Iinclude -I../include  -mmmx -m3dnow -msse -fvisibility=hidden
>>> -D_REENTRANT -DHAVE_LINUX_VERSION_H -Wall -MMD -MT build/SDL.lo -c
>>> ../src/SDL.c -o build/SDL.lo
>>> libtool: compile:  gcc -g -O3 -DUSING_GENERATED_CONFIG_H -Iinclude
>>> -I../include -mmmx -m3dnow -msse -fvisibility=hidden -D_REENTRANT
>>> -DHAVE_LINUX_VERSION_H -Wall -MMD -MT build/SDL.lo -c ../src/SDL.c  -fPIC
>>> -DPIC -o build/.libs/SDL.o
>>> In file included from ../include/SDL_main.h:25:0,
>>>                  from ../include/SDL.h:66,
>>>                  from ../src/SDL.c:25:
>>> ../include/SDL_stdinc.h: In function 'SDL_memcpy4':
>>> ../include/SDL_stdinc.h:429:16: error: 'len' undeclared (first use in
>>> this function)
>>> ../include/SDL_stdinc.h:429:16: note: each undeclared identifier is
>>> reported only once for each function it appears in
>>> make: *** [build/SDL.lo] Error 1
>>>
>>
>> Peeked at the code, SDL_stdinc.h, starting at line 415:
>>
>> SDL_FORCE_INLINE void *SDL_memcpy4(void *dst, const void *src, size_t
>>> dwords)
>>> {
>>> #if defined(__MACOSX__)
>>>     /* We can count on memcpy existing on Mac OS X and being well-tuned.
>>> */
>>>     return memcpy(dst, src, dwords * 4);
>>> #elif defined(__GNUC__) && defined(i386)
>>>     /* !!! FIXME: does this _really_ beat memcpy() on any modern
>>> platform? */
>>>     /* !!! FIXME: shouldn't we just force the inputs to ecx/edi/esi
>>> instead of this tapdance with outputs? */
>>>     /* !!! FIXME: amd64? */
>>>     int ecx, edi, esi;
>>>     __asm__ __volatile__ (
>>>         "cld \n\t"
>>>         "rep ; movsl \n\t"
>>>         : "=&c" (ecx), "=&D" (edi), "=&S" (esi)
>>>         : "0" (SDL_static_cast(unsigned, len)), "1" (dst), "2" (src)
>>>         : "memory"
>>>     );
>>>     return dst;
>>> #else
>>>     return SDL_memcpy(dst, src, dwords * 4);
>>> #endif
>>> }
>>>
>>
>> It appears that line 429 tries to access a variable "len" when one hasn't
>> been declared.
>>
>> Ryan, there is a good possiblity you accidentally broke it last push.
>>
>> -Alex
>>
>> On Fri, Mar 15, 2013 at 1:08 PM, Nathaniel J Fries <nfries88 at yahoo.com>wrote:
>>
>>> **
>>> An issue of C++ implementing its own versions of C functions for
>>> const-correctness.
>>>
>>> Just cast the result of strchr using a simple C-style cast.
>>>
>>> Example:
>>>
>>>
>>>
>>>  Code:
>>>
>>>
>>> - SDL_FORCE_INLINE char *SDL_strrchr_inline(const char *str, int c) {
>>> return strrchr(str, c); }
>>> + SDL_FORCE_INLINE char *SDL_strrchr_inline(const char *str, int c) {
>>> return (char *)strrchr(str, c); }
>>>
>>>
>>>
>>>
>>> (the C++ "correct" way would be using const_cast; but C then you've got
>>> to create two versions of the functions, which is a fairly pointless
>>> endeavor).
>>>
>>>
>>> ------------------------------
>>>
>>> Nate Fries
>>>
>>> _______________________________________________
>>> SDL mailing list
>>> SDL at lists.libsdl.org
>>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>>
>>>
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org
>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>
>>
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org
>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>
>>
>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130315/5f71d77b/attachment-0009.htm>


More information about the SDL mailing list