Skip to content

Cannot build tuple-keydef with Tarantool 2.10.3-0-g8aca8a1 #24

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
ylobankov opened this issue Oct 3, 2022 · 4 comments · Fixed by #27
Closed

Cannot build tuple-keydef with Tarantool 2.10.3-0-g8aca8a1 #24

ylobankov opened this issue Oct 3, 2022 · 4 comments · Fixed by #27
Labels
build

Comments

@ylobankov
Copy link

Environment:

OS:           macOS
OS Version:   11.6.8
Architecture: amd64

Tarantool:

Tarantool 2.10.3-0-g8aca8a1
Target: Darwin-x86_64-Release
Build options: cmake . -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/tarantool/2.10.3_1 -DENABLE_BACKTRACE=ON
Compiler: /usr/bin/clang /usr/bin/clang++
C_FLAGS: -Wno-unknown-pragmas -fexceptions -funwind-tables -fno-common -msse2 -Wformat -Wformat-security -Werror=format-security -fstack-protector-strong -fPIC -std=c11 -Wall -Wextra -Wno-strict-aliasing -Wno-char-subscripts -Wno-gnu-alignof-expression
CXX_FLAGS: -Wno-unknown-pragmas -fexceptions -funwind-tables -fno-common -msse2 -Wformat -Wformat-security -Werror=format-security -fstack-protector-strong -fPIC -std=c++11 -Wall -Wextra -Wno-strict-aliasing -Wno-char-subscripts -Wno-invalid-offsetof -Wno-gnu-alignof-expression

Steps to reproduce:

cmake .
make

Expected result:
Build is successful.

Actual result:

[ 14%] Building C object extra/CMakeFiles/txt2c.dir/txt2c.c.o
[ 28%] Linking C executable txt2c
[ 28%] Built target txt2c
[ 42%] Generating postload.lua.c
[ 57%] Building C object tuple/CMakeFiles/keydef.dir/util.c.o
[ 71%] Building C object tuple/CMakeFiles/keydef.dir/keydef.c.o
/Users/y.lobankov/Workspace/tuple-keydef/tuple/keydef.c:78:33: error: implicitly declaring library function 'strlen' with type 'unsigned long (const char *)' [-Werror,-Wimplicit-function-declaration]
        if (luaL_loadbuffer(L, modsrc, strlen(modsrc), modfile) != 0)
                                       ^
/Users/y.lobankov/Workspace/tuple-keydef/tuple/keydef.c:78:33: note: include the header <string.h> or explicitly provide a declaration for 'strlen'
/Users/y.lobankov/Workspace/tuple-keydef/tuple/keydef.c:158:9: error: implicitly declaring library function 'strstr' with type 'char *(const char *, const char *)' [-Werror,-Wimplicit-function-declaration]
        return strstr(path, "[*]") != NULL;
               ^
/Users/y.lobankov/Workspace/tuple-keydef/tuple/keydef.c:158:9: note: include the header <string.h> or explicitly provide a declaration for 'strstr'
/Users/y.lobankov/Workspace/tuple-keydef/tuple/keydef.c:378:3: error: implicitly declaring library function 'memcpy' with type 'void *(void *, const void *, unsigned long)' [-Werror,-Wimplicit-function-declaration]
                memcpy(tmp, path, path_len + 1);
                ^
/Users/y.lobankov/Workspace/tuple-keydef/tuple/keydef.c:378:3: note: include the header <string.h> or explicitly provide a declaration for 'memcpy'
3 errors generated.
make[2]: *** [tuple/CMakeFiles/keydef.dir/build.make:99: tuple/CMakeFiles/keydef.dir/keydef.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:160: tuple/CMakeFiles/keydef.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
@ylobankov ylobankov transferred this issue from tarantool/tuple-merger Oct 3, 2022
@ylobankov ylobankov changed the title Cannot build tuple-merger with Tarantool 2.10.3-0-g8aca8a1 Cannot build tuple-keydef with Tarantool 2.10.3-0-g8aca8a1 Oct 3, 2022
@Totktonada
Copy link
Member

Likely the root of the problem is the same as in tarantool/kafka#89.

@Totktonada Totktonada removed the osx label Oct 3, 2022
@Totktonada
Copy link
Member

Not Mac OS specific, reproduced on Linux.

@Totktonada Totktonada mentioned this issue Oct 3, 2022
Merged
@Totktonada
Copy link
Member

Caused by tarantool/tarantool#7663 (a modification of src/module_header.h).

@Totktonada
Copy link
Member

tarantoolctl rocks install tuple-keydef works well, because it uses the RelWithDebInfo build type (the command will show several warnings). Those warnings are errors only in the Debug build (it is default for cmake . && make flow, because it is usually used by developers).

Totktonada added a commit that referenced this issue Oct 3, 2022
@Totktonada
build: fix compilation against tarantool 2.10.3+
cba1a3b 
An inclusion of `string.h` header file was removed from
`tarantool/module.h` in tarantool 2.10.3, see [1].

This module uses `strstr()`, `strlen()` and `memcpy()` functions defined
by `string.h`, so it must include this header.

[1]: tarantool/tarantool#7663

Fixes #24
@Totktonada Totktonada mentioned this issue Oct 3, 2022
Merged
Totktonada added a commit that referenced this issue Oct 3, 2022
@Totktonada
ci: add pure cmake . && make build flow
90ffd6c 
The new CI rule ensures that a usual developer build flow is working. It
also improves testing by using the `Debug` build type, which adds the
`-Werror` compiler option. Compiler warnings are interpreted as errors
in this case.

It is inspired by #24, where the `Debug` build fails, but
`RelWithDebInfo` is fine.

This commit follows a spirit of [1], where it was declared that we
should verify as developer's flow as well as user's flow. We missed
developer's flow in CI of this module and now it is here.

[1]: tarantool/tarantool#6056
@Totktonada Totktonada mentioned this issue Oct 3, 2022
Merged
Totktonada added a commit that referenced this issue Oct 3, 2022
@Totktonada
ci: add pure cmake . && make build flow
366330a 
The new CI rule ensures that a usual developer build flow is working. It
also improves testing by using the `Debug` build type, which adds the
`-Werror` compiler option. Compiler warnings are interpreted as errors
in this case.

It is inspired by #24, where the `Debug` build fails, but
`RelWithDebInfo` is fine.

This commit follows a spirit of [1], where it was declared that we
should verify as developer's flow as well as user's flow. We missed
developer's flow in CI of this module and now it is here.

[1]: tarantool/tarantool#6056
Totktonada added a commit that referenced this issue Oct 3, 2022
@Totktonada
ci: add pure cmake . && make build flow
eadca28 
The new CI rule ensures that a usual developer build flow is working. It
also improves testing by using the `Debug` build type, which adds the
`-Werror` compiler option. Compiler warnings are interpreted as errors
in this case.

It is inspired by #24, where the `Debug` build fails, but
`RelWithDebInfo` is fine.

This commit follows a spirit of [1], where it was declared that we
should verify as developer's flow as well as user's flow. We missed
developer's flow in CI of this module and now it is here.

[1]: tarantool/tarantool#6056
Totktonada added a commit that referenced this issue Oct 4, 2022
@Totktonada
build: fix compilation against tarantool 2.10.3+
ddf1068 
An inclusion of `string.h` header file was removed from
`tarantool/module.h` in tarantool 2.10.3, see [1].

This module uses `strstr()`, `strlen()` and `memcpy()` functions defined
by `string.h`, so it must include this header.

The problem affects the `Debug` build type, which is default for the
`cmake . && make` build flow (it is usually used by developers of the
module). This build type adds `-Werror` compilation flag. However the
problem doesn't affect the `tarantoolctl rocks install tuple-keydef
[<version>]` build flow, because it uses the `RelWithDebInfo` build
type. All compiler warnings are just warnings here.

[1]: tarantool/tarantool#7663

Fixes #24
Totktonada added a commit that referenced this issue Oct 4, 2022
@Totktonada
build: fix compilation against tarantool 2.10.3+
fa575df 
An inclusion of `string.h` header file was removed from
`tarantool/module.h` in tarantool 2.10.3, see [1].

This module uses `strstr()`, `strlen()` and `memcpy()` functions defined
by `string.h`, so it must include this header.

The problem affects the `Debug` build type, which is default for the
`cmake . && make` build flow (it is usually used by developers of the
module). This build type adds `-Werror` compilation flag. However the
problem doesn't affect the `tarantoolctl rocks install tuple-keydef
[<version>]` build flow, because it uses the `RelWithDebInfo` build
type. All compiler warnings are just warnings here.

[1]: tarantool/tarantool#7663

Fixes #24
Totktonada added a commit that referenced this issue Oct 4, 2022
@Totktonada
ci: add pure cmake . && make build flow
56d5c19 
The new CI rule ensures that a usual developer build flow is working. It
also improves testing by using the `Debug` build type, which adds the
`-Werror` compiler option. Compiler warnings are interpreted as errors
in this case.

It is inspired by #24, where the `Debug` build fails, but
`RelWithDebInfo` is fine.

This commit follows a spirit of [1], where it was declared that we
should verify as developer's flow as well as user's flow. We missed
developer's flow in CI of this module and now it is here.

[1]: tarantool/tarantool#6056
Totktonada added a commit that referenced this issue Oct 4, 2022
@Totktonada
ci: add pure cmake . && make build flow
cd16819 
The new CI rule ensures that a usual developer build flow is working. It
also improves testing by using the `Debug` build type, which adds the
`-Werror` compiler option. Compiler warnings are interpreted as errors
in this case.

It is inspired by #24, where the `Debug` build fails, but
`RelWithDebInfo` is fine.

This commit follows a spirit of [1], where it was declared that we
should verify as developer's flow as well as user's flow. We missed
developer's flow in CI of this module and now it is here.

[1]: tarantool/tarantool#6056
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
build
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

build: fix compilation against tarantool 2.10.3+ tarantool/tuple-keydef
2 participants
@Totktonada @ylobankov