Bug 103194 – [GTK] Broken build with undefined references to shm_open / shm_unlink

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Kalev Lember]

Building webkitgtk-1.11.2 for rawhide (Fedora 19):

  CXXLD  Programs/WebKitPluginProcess
/usr/bin/ld: Source/WebKit2/Platform/unix/Programs_WebKitPluginProcess-SharedMemoryUnix.o: undefined reference to symbol 'shm_unlink@@GLIBC_2.2.5'
/usr/bin/ld: note: 'shm_unlink@@GLIBC_2.2.5' is defined in DSO /usr/lib64/librt.so.1 so try adding it to the linker command line
/usr/lib64/librt.so.1: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status

[Kalev Lember]

Created attachment 175871 [details]
Patch

[Martin Robinson]

Comment on attachment 175871 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=175871&action=review

> configure.ac:1128
> +       save_LIBS="$LIBS"
> +       AC_SEARCH_LIBS([shm_open], [rt], [SHM_LIBS="-lrt"])
> +       AC_SUBST(SHM_LIBS)
> +       LIBS="$save_LIBS"

What's going on here with save_LIBS?

[Kalev Lember]

AC_CHECK_LIB and AC_SEARCH_LIBS write the result to the LIBS variable and I didn't want to clobber the contents of the variable here. I'm using save_LIBS to restore the original LIBS after calling AC_SEARCH_LIBS(). Perhaps it doesn't make much of a difference right here and right now, but it can avoid surprises in the future.

I guess the macros were written with small build systems in mind where only one LIBS variable is sufficient; in webkitgtk with several libraries and executables produced, it seems better to avoid using the global LIBS variable.

For what it's worth, cairo does the same thing with save_LIBS: http://cgit.freedesktop.org/cairo/tree/configure.ac#n796

[Kalev Lember]

Or would it be better to do something like this? (untested)

       save_LIBS="$LIBS"
       LIBS=''
       AC_SEARCH_LIBS([shm_open], [rt])
       SHM_LIBS="$LIBS"
       AC_SUBST(SHM_LIBS)
       LIBS="$save_LIBS"

[Martin Robinson]

My preference is that we use this work-around for all instances of AC_SEARCH_LIBS or none of them. So far we haven't had an issue with it. Perhaps we can avoid it here and just be careful not to use a variable named LIBS? Let me know if I'm misunderstanding you.

[Kalev Lember]

Created attachment 176015 [details]
Patch v2

Fair enough, uploaded a new version with the save_LIBS workaround removed. I agree, should be fine as long as we avoid using LIBS.

[Martin Robinson]

Comment on attachment 176015 [details]
Patch v2

Thanks for fixing this!

[WebKit Review Bot]

Comment on attachment 176015 [details]
Patch v2

Rejecting attachment 176015 [details] from commit-queue.

Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2

Last 500 characters of output:
ls/Scripts/update-webkit line 108.

Failed to run "['Tools/Scripts/update-webkit', '--chromium', '--force-update']" exit_code: 2
hile loading dependencies of All.gyp while trying to load All.gyp
Error: 'depot_tools/gclient sync --force --reset --delete_unversioned_trees' failed 3 tries and returned 512 at Tools/Scripts/update-webkit-chromium line 96.
Re-trying 'depot_tools/gclient sync --force --reset --delete_unversioned_trees'
No such file or directory at Tools/Scripts/update-webkit line 108.

Full output: http://queues.webkit.org/results/14986694

[Martin Robinson]

Comment on attachment 176015 [details]
Patch v2

Clearing flags on attachment: 176015

Committed r135761: <http://trac.webkit.org/changeset/135761>

[Martin Robinson]

All reviewed patches have been landed.  Closing bug.

[Alberto Garcia]

*** Bug 104118 has been marked as a duplicate of this bug. ***