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

Alex Barry alex.barry at gmail.com
Fri Mar 15 13:09:47 PDT 2013


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130315/4e2cae5a/attachment-0009.htm>


More information about the SDL mailing list