This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Suppressing warnings about the needs of -fPIC for symbols that are unresolved?


Firstly, thank you for sharing the great tools, especially GNU gold linker.

I have come to realize there is a problem with a slightly misleading
warning for a LARGE project, though. So I am reporting it.

Background:

Here is a short set of files that shows the symptom of
missing symbol at link stage.
Basically, I put a slightly different parameter type in a function declaration in a
header file, a type different from the one I used in the function's
implementation in a c++ source file. The use of such function
in a different C++ source file would would lead to the link time error for C++.

Test files:
--- Begin quote Makefile ---
all: test-main

test-subr.o: test-subr.cpp
    g++-5 -c -gsplit-dwarf test-subr.cpp
test-main.o: test-main.cpp
    g++-5 -c -gsplit-dwarf test-main.cpp
test-main: test-main.o test-subr.o
    ld --version
    gcc-5 --version
    g++-5 --verbose -gsplit-dwarf -o test-main test-main.o test-subr.o
--- end quote

--- Begin quote test-main.cpp which calls FillRead()
#include <unistd.h>
#include <stdio.h>
#include "test-header.h"

char buf[512];
int
main() {
  int obtained;
  ssize_t rc;

  rc = FillRead(0, buf, 512, &obtained);
  return rc;
}
--- End quote test-main.cpp
--- Begin quote test-subr.cpp which implements FillRead()
#include "test-header.h"
#include <unistd.h>

ssize_t
FillRead(int d, char *cp, int len, int *reallen) {
  ssize_t rc;

  rc = read(d, cp, len);

  if(rc >= 0)
    *reallen = rc;
  return rc;
}
--- end quote test-subr.cpp
--- begin quote test-header.h which declares FillRead() with an incorrect type.

#include <unistd.h>
/*
 * Note that the second paramter is of type |void *cp| and
 * not |char *| as is declared in test-subr.cpp
 */
extern ssize_t FillRead(int d, void *cp, int len, int *reallen);

--- end

The warning from linking stage is shown in Warning-1 below. The function signatures
don't match, thus the failure.
I put the version number of GNU gold and GCC in Makefile which showed the
symptom I am discussing subsequently.
In the small test sample, the
message about "undefined reference" is loud and clear. All is fine.

But in a real world case of LARGE build of mozilla thunderbird mail
client which produces a library of almost 1GB (well actually 500MB or
so) without -gsplit-dwarf (I use GNU gold here and use -gsplit-dwarf, though), GNU gold linker prints MANY spurious "requires dynamic R_X86_64_PC32 reloc against
'_Z15FullyReadStreamP14nsIInputStreamPvjPj' which may overflow at
runtime; recompile with -fPIC" about a symbol as in Warning-2. And the symbol
turned out to be unresolved at the end: function name and the
parameters are slightly changed.)

========================================
Warning-1:
----------------------------------------

-*- mode: compilation; default-directory: "/tmp/" -*-
Compilation started at Sun Jan 24 23:14:36

make -k
ld --version
GNU gold (GNU Binutils 2.26.51.20160102) 1.11
Copyright (C) 2016 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
gcc-5 --version
gcc-5 (Debian 5.3.1-4) 5.3.1 20151219
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

g++-5 --verbose -gsplit-dwarf -o test-main test-main.o test-subr.o
Using built-in specs.
COLLECT_GCC=g++-5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20151219 (Debian 5.3.1-4)
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-gsplit-dwarf' '-o' 'test-main' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/5/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper -plugin-opt=-fresolution=/tmp/ccMsY9GA.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test-main /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/5 -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/5/../../.. test-main.o test-subr.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/5/crtend.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crtn.o test-main.cpp:11: error: undefined reference to 'FillRead(int, void*, int, int*)'
collect2: error: ld returned 1 exit status
Makefile:8: recipe for target 'test-main' failed
make: *** [test-main] Error 1
make: Target 'all' not remade because of errors.

Compilation exited abnormally with code 2 at Sun Jan 24 23:14:36

========================================
Warning-2: real-world case: Mozilla Thunderbid development (function names and types are slightly different)
----------------------------------------

        ... finally linking stage of a library called libxul.o ...

Executing: /usr/bin/ccache /usr/bin/g++-5 -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wtype-limits -Wunreachable-code -Wcast-align -Wno-invalid-offsetof -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -gsplit-dwarf -g -Og -fno-omit-frame-pointer -freorder-blocks -fno-omit-frame-pointer -fPIC -shared -Wl,-z,defs -Wl,-h,libxul.so -o libxul.so /NREF-COMM-CENTRAL/objdir-tb3/toolkit/library/tmp8DVHzF.list -lpthread -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id -Wl,-version-script,symverscript -Wl,-rpath-link,/NREF-COMM-CENTRAL/objdir-tb3/dist/bin -Wl,-rpath-link,/usr/local/lib ../../js/src/libjs_static.a ../../js/src/libjs_static.a ../../intl/icu/target/lib/libicui18n.a ../../intl/icu/target/lib/libicuuc.a ../../intl/icu/target/lib/libicudata.a ../../security/nss/lib/crmf/libcrmf.a ../../js/src/libjs_static.a ../../ldap/c-sdk/libraries/libldap/libldap60.so ../../ldap/c-sdk/libraries/libldif/libldif60.so ../../ldap/c-sdk/libraries/libprldap/libprldap60.so ../../nsprpub/lib/ds/libplds4.so ../../nsprpub/lib/libc/src/libplc4.so ../../nsprpub/pr/src/libnspr4.so ../../security/nss/lib/nss/libnss3.so ../../security/nss/lib/smime/libsmime3.so ../../security/nss/lib/ssl/libssl3.so ../../security/nss/lib/util/libnssutil3.so ../../config/external/sqlite/libmozsqlite3.so ../../config/external/lgpllibs/liblgpllibs.so ../../widget/gtk/mozgtk/stub/libmozgtk_stub.so -ldl -lm -ldl -lfreetype -lfontconfig -lrt -lXrender -lXext -lXdamage -lXfixes -lXcomposite -lasound -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lglib-2.0 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lX11 -lpangoft2-1.0 -lXt -lgthread-2.0
/NREF-COMM-CENTRAL/objdir-tb3/toolkit/library/tmp8DVHzF.list:
    INPUT("StaticXULComponentsStart.o")
    INPUT("../../memory/volatile/Unified_cpp_memory_volatile0.o")
    INPUT("../../media/kiss_fft/kiss_fft.o")
    INPUT("../../media/kiss_fft/kiss_fftr.o")
    INPUT("../../media/libstagefright/fake_log_device.o")
    ....
    many lines (# of objects, I think)
    ...
    INPUT("../../modules/zlib/src/trees.o")
    INPUT("../../modules/zlib/src/uncompr.o")
    INPUT("../../modules/zlib/src/zutil.o")
    INPUT("StaticXULComponentsEnd/StaticXULComponentsEnd.o")

/usr/local/bin/ld: error: /NREF-COMM-CENTRAL/objdir-tb3/toolkit/library/../../mailnews/base/src/nsMessenger.o: requires dynamic R_X86_64_PC32 reloc against '_Z15FullyReadStreamP14nsIInputStreamPvjPj' which may overflow at runtime; recompile with -fPIC /usr/local/bin/ld: error: /NREF-COMM-CENTRAL/objdir-tb3/toolkit/library/../../mailnews/base/src/nsMsgFolderCompactor.o: requires dynamic R_X86_64_PC32 reloc against '_Z15FullyReadStreamP14nsIInputStreamPvjPj' which may overflow at runtime; recompile with -fPIC /usr/local/bin/ld: error: /NREF-COMM-CENTRAL/objdir-tb3/toolkit/library/../../mailnews/base/util/nsMsgDBFolder.o: requires dynamic R_X86_64_PC32 reloc against '_Z15FullyReadStreamP14nsIInputStreamPvjPj' which may overflow at runtime; recompile with -fPIC

... many lines of misleading warnings about -fPIC to overwhelm
                   the developer ...

amP14nsIInputStreamPvjPj' which may overflow at runtime; recompile with -fPIC /usr/local/bin/ld: error: /NREF-COMM-CENTRAL/objdir-tb3/toolkit/library/../../mailnews/import/src/nsImportScanFile.o: requires dynamic R_X86_64_PC32 reloc against '_Z15FullyReadStreamP14nsIInputStreamPvjPj' which may overflow at runtime; recompile with -fPIC
/usr/local/bin/ld: error: read-only segment has dynamic relocations
/NREF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMessenger.cpp:1997: error: undefined rgeference to 'FullyReadStream(nsIInputStream*, void*, unsigned int, unsigned int*)' /NREF-COMM-CENTRAL/objdir-tb3/toolkit/library/../../mailnews/base/src/nsMessenger.o(.debug_addr+0xdcb8): error: undefined reference to 'FullyReadStream(nsIInputStream*, void*, unsigned int, unsigned int*)' /NREF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgFolderCompactor.cpp:828: error: undefined reference to 'FullyReadStream(nsIInputStream*, void*, unsigned int, unsigned int*)'

In the case of Mozilla Thunderbird, I defined  function
FullyReadStream(nsIInputStream*, char*, unsigned int unsigned int*), i.e., with a parameter of |char *| insated of |void *| at the second position in the parameter list. Thus the signatures did not match and so we had an unresolved symbol error.

Summary and Request:

Finally at the end of -fPIC warnings which overwhelmed a typical
developer initially, we get the undefined reference error. So actually
-fPIC was not necessary after all (I recompiled the source which took me a couple of hours or so, and only then realized there is something wrong.) However the unresolved error was buried in the
preceding warnings about -fPIC and I was misled initially.

My question:

Can we possibly suppress the warning line of "-fPIC" if the related
symbol turns out to be undefined in the end?
(This may involve deferring the print out of -fPIC until all the symbols are resolved:
Oh, come to think of it, if we do explicit dynamic loading or
something, this will be impossible. We will not know, for sure, if the
symbol in question is finally resolved or not until run-time.  But
mozilla TB and many programs do not do that intentionally.)

TIA



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]