I got this error when compiling WebKit trunk with debug on FreeBSD: Linking CXX shared library ../../../lib/libgtest.so CMakeFiles/gtest.dir/__/__/ThirdParty/gtest/src/gtest-death-test.cc.o: In function `testing::internal::GetEnviron()': /usr/home/lantw44/webkit/source/WebKit/Source/ThirdParty/gtest/src/gtest-death-test.cc:846: undefined reference to `environ' It seems it is caused by the -Wl,--no-undefined flag added in Source/cmake/OptionsCommon.cmake. The environ symbol is not defined in libc.so.7, but it exists in crt1.o.
Created attachment 241660 [details] Work around undefined reference error for gtest on FreeBSD
Created attachment 245137 [details] Work around undefined reference error for gtest on FreeBSD
Created attachment 256294 [details] Patch
Comment on attachment 256294 [details] Patch This bug should probably be fixed upstream and the fix should probably not leave symbols unresolved.
(In reply to comment #4) > Comment on attachment 256294 [details] > Patch > > This bug should probably be fixed upstream and The upstream project doesn't have this problem because they don't use -Wl,--no-undefined. > the fix should probably not leave symbols unresolved. I leave it unresolved because I can't find other ways to solve the problem. The environ symbol doesn't exist in any shared library, so it can't be resolved by adding -l arguments. I also tried to add crt1.o to the linking arguments, but it also doesn't work. If I use /usr/lib/crt1.o: ld: /usr/lib/crt1.o: relocation R_X86_64_32 against `_DYNAMIC' can not be used when making a shared object; recompile with -fPIC /usr/lib/crt1.o: error adding symbols: Bad value clang++: error: linker command failed with exit code 1 (use -v to see invocation) If I use /usr/lib/gcrt1.o: ld: /usr/lib/gcrt1.o: relocation R_X86_64_32 against `_DYNAMIC' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcrt1.o: error adding symbols: Bad value clang++: error: linker command failed with exit code 1 (use -v to see invocation) If I use /usr/lib/Scrt1.o: /usr/lib/Scrt1.o: In function `_start': /usr/src/lib/csu/amd64/crt1.c:(.text+0xa4): undefined reference to `__preinit_array_start' ld: /usr/lib/Scrt1.o: relocation R_X86_64_PC32 against undefined hidden symbol `__preinit_array_start' can not be used when making a shared object ld: final link failed: Bad value clang++: error: linker command failed with exit code 1 (use -v to see invocation)
(In reply to comment #5) > (In reply to comment #4) > > Comment on attachment 256294 [details] > > Patch > > > > This bug should probably be fixed upstream and > > The upstream project doesn't have this problem because they don't use > -Wl,--no-undefined. I think a proper fix upstream would be to not use environ based on some conditional compilation flag.
I sent a message to gtest upstream: https://groups.google.com/forum/#!topic/googletestframework/wrrMj_fmXMc I hope I will get a reply ...
I don't think I quite understand the problem, what crt1.o is and why gtest does not link to it. Asking upstream to not use environ does not seem reasonable, and dropping use of --no-undefined does not seem desirable either.
crt1.o contains the entrypoint of a C program, _start function. _start function makes argc, argv, environ and possibly other initialization works, and calls main function. environ global variable is in crt1.o on FreeBSD. crt1.c, the file containing _start function: http://svn.freebsd.org/base/releng/10.1/lib/csu/amd64/crt1.c ignore_init.c, the file included by crt1.c and containing environ variable: http://svn.freebsd.org/base/releng/10.1/lib/csu/common/ignore_init.c When using a C compiler driver to make an executable, crt1.o and other crt*.o files are automatically added to the linker arguments. This can be found by running 'cc -v'. gtest doesn't link to it because it is a shared library. It is not an executable and it does not have a vaild entrypoint.
Created attachment 256844 [details] Patch
Comment on attachment 256844 [details] Patch This can't hurt anything, so go ahead, but please add a note to Source/ThirdParty/gtest/README.WebKit.
Created attachment 268072 [details] Remove usage of environ in gtest
I don't have commit privilege, so I have to get the patch reviewed again to add a note in Source/ThirdParty/gtest/README.WebKit.
Comment on attachment 268072 [details] Remove usage of environ in gtest View in context: https://bugs.webkit.org/attachment.cgi?id=268072&action=review > Source/ThirdParty/gtest/src/gtest-death-test.cc:861 > DeathTestAbort(String::Format("execve(%s, ...) in %s failed: %s", Oops, should probably update this string too.
Created attachment 268085 [details] Remove usage of environ in gtest
Comment on attachment 268085 [details] Remove usage of environ in gtest Thanks. In the future, please set cq? to request commit.
Comment on attachment 268085 [details] Remove usage of environ in gtest Rejecting attachment 268085 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-03', 'validate-changelog', '--check-oops', '--non-interactive', 268085, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit /Volumes/Data/EWS/WebKit/Source/ThirdParty/ChangeLog neither lists a valid reviewer nor contains the string "Unreviewed" or "Rubber stamp" (case insensitive). Full output: http://webkit-queues.webkit.org/results/639848
Created attachment 268104 [details] Patch
Comment on attachment 268104 [details] Patch Clearing flags on attachment: 268104 Committed r194501: <http://trac.webkit.org/changeset/194501>
All reviewed patches have been landed. Closing bug.