Skip to content

Compilation broken on Linux #10

Description

@Lane-Powell

First attempt to compile yielded suchlike errors:

../include/font/font.h:4:10: fatal error: gs/gs.h: No such file or directory
4 | #include <gs/gs.h>
| ^~~~~~~~~
compilation terminated.

In an attempt to fix, it replaced every instance of "#include <gs/gs.h>" with a correct include path according to the project's directory structure. Then I got this:

In file included from ../source/gs/gs.h:6750,
from ../source/main.c:2:
../source/gs/external/stb/stb_image.h: In function ‘stbi__parse_png_file’:
../source/gs/external/stb/stb_image.h:4877:56: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
4877 | for (k = 0; k < s->img_n; ++k) tc[k] = (stbi_uc)(stbi__get16be(s) & 255) * stbi__depth_scale_table[z->depth]; // non 8-bit images will be larger
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../source/gs/external/stb/stb_image.h:4796:25: note: at offset 3 into destination object ‘tc’ of size 3
4796 | stbi_uc has_trans=0, tc[3]={0};
| ^~
In file included from /usr/include/string.h:580,
from ../source/gs/gs.h:493:
In function ‘memcpy’,
inlined from ‘gs_immediate_draw_static_data_init’ at ../source/gs/util/gs_idraw.h:323:2:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10: warning: ‘__builtin_memcpy’ reading 64 bytes from a region of size 6 [-Wstringop-overread]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘memcpy’,
inlined from ‘gs_immediate_draw_static_data_init’ at ../source/gs/util/gs_idraw.h:331:2:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10: warning: ‘__builtin_memcpy’ reading 64 bytes from a region of size 6 [-Wstringop-overread]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘memcpy’,
inlined from ‘gs_immediate_draw_static_data_init’ at ../source/gs/util/gs_idraw.h:359:2:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10: warning: ‘__builtin_memcpy’ reading 64 bytes from a region of size 33 [-Wstringop-overread]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘memcpy’,
inlined from ‘gs_immediate_draw_static_data_init’ at ../source/gs/util/gs_idraw.h:363:65:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10: warning: ‘__builtin_memcpy’ reading 64 bytes from a region of size 11 [-Wstringop-overread]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘memcpy’,
inlined from ‘gs_immediate_draw_static_data_init’ at ../source/gs/util/gs_idraw.h:364:65:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10: warning: ‘__builtin_memcpy’ reading 64 bytes from a region of size 5 [-Wstringop-overread]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘memcpy’,
inlined from ‘gs_immediate_draw_static_data_init’ at ../source/gs/util/gs_idraw.h:365:64:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10: warning: ‘__builtin_memcpy’ reading 64 bytes from a region of size 8 [-Wstringop-overread]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/x86_64-linux-gnu-ld.bfd: cannot find -lgunslinger: No such file or directory
collect2: error: ld returned 1 exit status

At which point I gave up. I'm not sure how serious the warnings are, but the final message, as well as the earlier include errors, may point to the code being tailored to assumptions about how the gunslinger framework is installed, regardless of the project structure. The fix in PR#7 works fine which seems to confirm that.

I know this is an old project, but I'm currently making a falling sand sim of my own and enjoy messing with others' :)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions