Bug 188440 – [WPE] Build failure on fedora when not adding -lrt as a cmake linker flag.

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: WPE WebKit

[Chris King]

When trying to package WPE for Fedora, I have run into a problem where building fails complaining about not finding shm_open unless I add -lrt to CMAKE_EXE_LINKER_FLAGS. Additionally, when building on either 32 bit or 64 bit ARM, I need to add -lrt to CMAKE_SHARED_LINKER_FLAGS in order to not run into the same issue. This seems like it shouldn't be necessary.

Here is the spec file that currently works: https://src.fedoraproject.org/rpms/wpewebkit/blob/master/f/wpewebkit.spec

And here is the package review request with more information: https://bugzilla.redhat.com/show_bug.cgi?id=1601186

Thanks,

Chris

[Michael Catanzaro]

Konstantin wrote this check in Source/WebKit/CMakeLists.txt:

if (UNIX)
    check_function_exists(shm_open SHM_OPEN_EXISTS)
    if (NOT SHM_OPEN_EXISTS)
        set(CMAKE_REQUIRED_LIBRARIES rt)
        check_function_exists(shm_open SHM_OPEN_REQUIRES_LIBRT)
        if (SHM_OPEN_REQUIRES_LIBRT)
            list(APPEND WebKit_LIBRARIES PRIVATE rt)
        endif ()
        unset(CMAKE_REQUIRED_LIBRARIES)
    endif ()
endif ()

It's not working for some reason, and I'm not sure why. Weird is that it *does* work for WebKitGTK+ on the same build infrastructure.

The main difference I see is package version. The latest WPE 2.21 is significantly older than the latest GTK 2.21.

[Konstantin Tokarev]

I've looked at Koji log and see there `-DCMAKE_EXE_LINKER_FLAGS= -lrt` passed to cmake arguments. It makes check_function_exists() test pass without -lrt flag, however CMAKE_EXE_LINKER_FLAGS does not affect building libraries

[Konstantin Tokarev]

I think that indiscriminate forcing of -lrt on all cmake-based packages in repository is not a good practice, but if you force it on executables, you should also force it on other target types to avoid situations like this one.

[Michael Catanzaro]

(In reply to Konstantin Tokarev from comment #3)
> I think that indiscriminate forcing of -lrt on all cmake-based packages in
> repository is not a good practice

We don't do that, it's added only for WebKit, and only to work around this build failure:

%cmake \
  -DPORT=WPE \
  -DCMAKE_BUILD_TYPE=Release \
  -DENABLE_MINIBROWSER=ON \
  -DCMAKE_EXE_LINKER_FLAGS="${CMAKE_EXE_LINKER_FLAGS} -lrt" \
  -DCMAKE_SHARED_LINKER_FLAGS="${CMAKE_SHARED_LINKER_FLAGS} -lrt" \
%ifarch s390 aarch64
  -DUSE_LD_GOLD=OFF \
%endif
%ifarch s390 s390x ppc %{power64}
  -DENABLE_JIT=OFF \
  -DUSE_SYSTEM_MALLOC=ON \
%endif
..
popd

These lines:

  -DCMAKE_EXE_LINKER_FLAGS="${CMAKE_EXE_LINKER_FLAGS} -lrt" \
  -DCMAKE_SHARED_LINKER_FLAGS="${CMAKE_SHARED_LINKER_FLAGS} -lrt" \

are needed to build WPE, but not GTK. That's weird. They should be removed once this issue is resolved.







Unrelated: Chris, these lines:

%ifarch s390 s390x ppc %{power64}
  -DENABLE_JIT=OFF \
  -DUSE_SYSTEM_MALLOC=ON \
%endif

should be possible to remove since https://trac.webkit.org/changeset/232918/webkit/trunk/Source/cmake, but the current WPE release 2.21.2 is older than that commit, so that will have to wait for the next release.

[Konstantin Tokarev]

Chris: Could you try building without forcing -lrt in spec, and share your cmake output, CMakeFiles/CMakeOutput.log and CMakeFiles/CMakeError.log?

[Chris King]

(In reply to Konstantin Tokarev from comment #5)
> Chris: Could you try building without forcing -lrt in spec, and share your
> cmake output, CMakeFiles/CMakeOutput.log and CMakeFiles/CMakeError.log?

I'll give it a go, it'll be a while before that finishes though. I'll update with those files once it fails. Additionally, (to my newbie knowledge at least) there is no way to get those file from a fedora infra build, so I'll do it on my personal machine, meaning it is not *fully* representative of the exact build environment.

[Michael Catanzaro]

If you do the build in mock it *should* be the same as a build on koji. I agree mock build is best, since there's indeed no easy way to get those files from a koji build.

[Adrian Perez]

(In reply to Michael Catanzaro from comment #4)
> Unrelated: Chris, these lines:
> 
> %ifarch s390 s390x ppc %{power64}
>   -DENABLE_JIT=OFF \
>   -DUSE_SYSTEM_MALLOC=ON \
> %endif
> 
> should be possible to remove since
> https://trac.webkit.org/changeset/232918/webkit/trunk/Source/cmake, but the
> current WPE release 2.21.2 is older than that commit, so that will have to
> wait for the next release.

Related: I am planning to make a new 2.21.3 release of WPE in a few days,
currently on hold waiting for releases of WPEBackend and WPEBackend-fdo.
Then you will be able to remove these lines :-)

[Chris King]

(In reply to Konstantin Tokarev from comment #5)
> Chris: Could you try building without forcing -lrt in spec, and share your
> cmake output, CMakeFiles/CMakeOutput.log and CMakeFiles/CMakeError.log?

Weirdly, in my f29 mock environment it successfully built on x86... That said, I think I remember that it did fail when trying to build on x86 when I didn't pass the lrt flag, at least in copr. This is very weird.

[Michael Catanzaro]

You can try a merge request on https://src.fedoraproject.org/rpms/wpewebkit/blob/master/f/wpewebkit.spec to remove those the -lrt; it should run a test build without needing to merge the change into master. See the sidebar in https://src.fedoraproject.org/rpms/at-spi2-core/pull-request/2# for example.

[Chris King]

(In reply to Michael Catanzaro from comment #10)
> You can try a merge request on
> https://src.fedoraproject.org/rpms/wpewebkit/blob/master/f/wpewebkit.spec to
> remove those the -lrt; it should run a test build without needing to merge
> the change into master.

Good idea, I have done that and it is now building.

Here is the running koji build which will have all of the build logs etc: https://koji.fedoraproject.org/koji/taskinfo?taskID=28970190

Unfortunately this still won't give us access to the CMAKE error logs and other files requested :(

[Konstantin Tokarev]

(In reply to Chris King from comment #11)
> Unfortunately this still won't give us access to the CMAKE error logs and other files requested :(

That's sad.

How do you people debug configure tests? E.g. with autotools one needs to access config.log file to know details.

[Chris King]

(In reply to Konstantin Tokarev from comment #12)
> How do you people debug configure tests? E.g. with autotools one needs to
> access config.log file to know details.

I am quite new to the Fedora ecosystem so I can't say for sure how that is supposed to be done, but I believe the mock environment is supposed to be a copy of the build server environment.

Interestingly, the x86 and other non arm architecture builds have succeeded without the -lrt, so I'm either misremembering the copr failure or there is some difference between the configuration of the fedora build servers and copr build servers that causes one to fail while the other doesn't.

(In reply to Adrian Perez from comment #8)
> Related: I am planning to make a new 2.21.3 release of WPE in a few days,
> currently on hold waiting for releases of WPEBackend and WPEBackend-fdo.
> Then you will be able to remove these lines :-)

Thanks for letting me know Adrian! Can't wait for that release!

[Michael Catanzaro]

The build at https://koji.fedoraproject.org/koji/taskinfo?taskID=28970190 passed on all architectures, so I think we should just remove those lines from the spec file.

[Chris King]

(In reply to Michael Catanzaro from comment #14)
> The build at https://koji.fedoraproject.org/koji/taskinfo?taskID=28970190
> passed on all architectures, so I think we should just remove those lines
> from the spec file.

I feel like I must've done something wrong with the forking... It was for sure failing just a few days ago **at least** on the arm arches. I am now doing a scratch build directly from an srpm I built from a spec file without those flags so this build for sure doesn't have those flags.

If this build also passes on all arches then I guess something really did change within the last few days on the build architecture that miraculously fixed this issue.

Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=28988733

[Chris King]

Huh, it successfully built... Well then, I'll remove those lines, sorry for reporting a bug that doesn't exist anymore & thanks for everyone's help!