Skip to content
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.

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

Linux build with native SDK and GLIBC 2.27 #94

Closed
MouhK opened this issue Nov 21, 2019 · 8 comments
Closed

Linux build with native SDK and GLIBC 2.27 #94

MouhK opened this issue Nov 21, 2019 · 8 comments
Labels
enhancement New feature or request

Comments

@MouhK
Copy link

MouhK commented Nov 21, 2019

Hello,

Using the native SDK with GLIBC 2.27 crashpad doesn't seem to build.
I get the following error:

../crashpad/build/crashpad/compat/linux/sys/mman.cc:25:5: error: 'memfd_create' is missing exception specification 'throw()'
6669 int memfd_create(const char* name, unsigned int flags) {
6670     ^
6671                                                        throw()
6672 ../crashpad/build/crashpad/compat/linux/sys/mman.h:32:5: note: previous declaration is here
6673 int memfd_create(const char* name, unsigned int flags);
6674     ^
6675 1 error generated.
6676 make[1]: *** [obj/Release/crashpad_util/mman.o] Error 1

The thing is that there's no memfd_create() wrapper before glibc 2.27 and in "sentry-native/crashpad/build/crashpad/compat/linux/sys/mman.h" it makes the wrapper if GLIBC is defined instead of checking if GLIBC is < 2.27.

Checking if the version is < 2.27 works.

Thanks

@bjorn
Copy link

bjorn commented Nov 26, 2019

So in particular, this is about the following code in crashpad, which has a comment about why it can't check the GLIBC version:

https://github.com/getsentry/crashpad/blob/2fb4e9e6a4328ed49b15eec0a848fcc646208840/compat/linux/sys/mman.h#L22-L38

Rather than checking the version, it seems to be enough to actually add the throw() bit in the .cc file, to get it to compile at least (I haven't tested the resulting binary).

@mitsuhiko mitsuhiko added the enhancement New feature or request label Nov 30, 2019
@mitsuhiko
Copy link
Member

I think the right fix here would be to make sure the throw specified is on there for C++. I'm just not sure if all glibc versions have that or if that then breaks it for other setups.

@Swatinem
Copy link
Member

I will close this for now, as this is specific to crashpad on linux, which we do not yet support. We will revisit this in a few weeks after we have breakpad support ready.

@plq
Copy link

plq commented May 3, 2020

This is only a problem with a recent clang in c++17 mode as both clang -std=c++14 and GCC (I only tried c++17) seem to work fine.

The workaround thus is the following:

if (LINUX AND CLANG)  # <- pseudocode
    set_property(
        SOURCE /path/to/crashpad/compat/linux/sys/mman.cc
        APPEND PROPERTY COMPILE_FLAGS "-std=c++14"
    )
endif()

I'm using cmake files generated by a slightly modified version of gn_to_cmake.py on windows, darwin and linux without any problems. The above should come right after include()'ing the generated CMakeFiles.ext file.

@Swatinem
Copy link
Member

Swatinem commented May 4, 2020

gn_to_cmake.py

oh nice! I wish I knew about that one before

@plq
Copy link

plq commented May 4, 2020

I dug a bit more: glibc-2.26 does not have this function. glibc-2.27 and later has it, always with __THROW in the declaration. __THROW is a glibc macro which compiles to nothing for gcc and select (very old) g++ versions.

If it's desired to avoid preprocessor checks, one can check with cmake (or gn) to see whether this function exists and compile mman.cc selectively.

@plq
Copy link

plq commented May 4, 2020

The right thing to do is to patch crashpad to have __THROW in both declaration and definition of the said function as that's what it's trying to imitate here. Checking for glibc version is the wrong approach imo.

@plq
Copy link

plq commented May 4, 2020

https://bugs.chromium.org/p/crashpad/issues/detail?id=339

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants