Resubmitting as wasn't sub'd to list and thought it might have
bounced it...?
Also, on another list, someone mentioned that libtool might
be involved, as it would have to store the gimble output in
a lib -- and squid makes several statically linked binaries for
helpers and such that end up w/a ".la" extension or ".a"
extension. when I dumped one of the ".a" files the devel
asked for (that had some of the missing symbols)... it showed
all zeros:
squid-3.5.7> nm compat/.libs/libcompat-squid.a
assert.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
compat.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
debug.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
eui64_aton.o:
U __isoc99_sscanf
0000000000000000 T eui64_aton
getaddrinfo.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
getnameinfo.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
GnuRegex.o:
inet_ntop.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
inet_pton.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
memrchr.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
shm.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
statvfs.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
strnstr.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
strnrchr.o:
0000000000000000 T strnrchr
xalloc.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
xstrerror.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
xstring.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
xstrto.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
mswindows.o:
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
-------------
Which he said indicated none of the missing symbols
that were in that library, were being exported.
Maybe that's part of the problem? Does libtool keep
both the native and gimple code when linking to ".la"
or .a extensions?
If it didn't keep the gimple around seems like would make
the final link stage complain about missing symbols?
When I looked at a one
I've been using -flto with most of my builds without problems.
(+ -fuse-linker-plugin w/LD @ link)
Then I got to squid-3.5.7 which had its own version
with options for it in its configure. I tried the
generic version ?2.2? in my distro and link options I'd
used w/other tools -- not good. It never played well
with the gcc4.9 I had installed (@ final link -- *MANY*
things were 'unresolved'.
So next I tried it's configure options to use lto and use the
one it included -- which I guess got installed w/my libs --
though I never got the -flto option included at 'g++' or link
time to work. But somehow managed to get it installed over the
other copy that was 'somewhere', as now my "other builds" (like
of bash, no longer work with the same missing symbols messages.
At one point (maybe during configure) I thought I saw something
about a 2.2 obj being seen while a 3.0 obj was expected.... but
couldn't reproduce that message so not sure of the exact text.
Looked for the source for lto and found gnu page:
https://gcc.gnu.org/wiki/LinkTimeOptimization
...followed instructions there and a few variations:
nothing would generate lto or any installable.
Error messages center around some struct sizes:
/usr/bin/gcc -c -DHAVE_CONFIG_H -g -fkeep-inline-functions -I.
-I../../lto/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic -fpic ../../lto/libiberty/physmem.c -o
pic/physmem.o; \
else true; fi
../../lto/libiberty/physmem.c: In function 'physmem_total':
../../lto/libiberty/physmem.c:96:23: error: storage size of 'pss' isn't
known
struct pst_static pss;
^
../../lto/libiberty/physmem.c:97:5: warning: implicit declaration of
function 'pstat_getstatic' [-Wimplicit-function-declaration]
if (0 <= pstat_getstatic (&pss, sizeof pss, 1, 0))
^
../../lto/libiberty/physmem.c:96:23: warning: unused variable 'pss'
[-Wunused-variable]
struct pst_static pss;
^
../../lto/libiberty/physmem.c: In function 'physmem_available':
../../lto/libiberty/physmem.c:200:23: error: storage size of 'pss' isn't
known
struct pst_static pss;
^
../../lto/libiberty/physmem.c:201:24: error: storage size of 'psd' isn't
known
struct pst_dynamic psd;
^
../../lto/libiberty/physmem.c:203:2: warning: implicit declaration of
function 'pstat_getdynamic' [-Wimplicit-function-declaration]
&& 0 <= pstat_getdynamic (&psd, sizeof psd, 1, 0))
^
../../lto/libiberty/physmem.c:201:24: warning: unused variable 'psd'
[-Wunused-variable]
struct pst_dynamic psd;
^
../../lto/libiberty/physmem.c:200:23: warning: unused variable 'pss'
[-Wunused-variable]
struct pst_static pss;
^
make[3]: *** [physmem.o] Error 1
make[3]: Leaving directory `/home/tools/lto/bld/libiberty'
make[2]: *** [all-stage1-libiberty] Error 2
make[2]: Leaving directory `/home/tools/lto/bld'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/tools/lto/bld'
make: *** [all] Error 2
The symptom of some mismatch is in *either* squid or bash, if I use the
-flto option in CFLAGS -- I gets tons of undefined symbols.
W/o -flto in bash I get final stripped binary about 200K larger...
Don't know the improvement on squid, but would likely have been 5x larger
as the binary was.
I'm using gcc-4.9 tool chain on linux 4.1.0.
Any ideas where I can find the source for this option and get builds
synced-up -- and hopefully both using the newer version, as that seems
to be the one included in squid these days. *sigh*
Thanks for any pointers or if this is the wrong place, where to
direct this...
linda
