> Ben Taylor wrote:
>
> > pkgbuild: Undefined first
> referenced
> > pkgbuild: symbol in file
> > pkgbuild: .CGB0.3612
> ../glib/.libs/libglib-2.0.so
> ../glib/.libs/libglib-2.0.so
> b has references to these two symbols, which are
> remaining unresolved at the time you build your app.
>
> If you return to your libglib build, you can turn on
> ld(1)'s debugging
> and determine where these references are coming from.
>
> Set LD_OPTIONS=-Dsymbols,detail.
>
> You'll get (lots) of output on stderr defining which
> symbols come from
> which input files, and how they get resolved.
On Sun, Nov 29, 2009 at 12:15 AM, Rod Evans <Rod.Evans at sun.com> wrote:
> Ben Taylor wrote:
>>
>> On Sat, Nov 28, 2009 at 10:59 PM, Rod Evans <Rod.Evans at sun.com> wrote:
>>>
>>> Ben Taylor wrote:
>>>
>>>> pkgbuild: Undefined first referenced
>>>> pkgbuild: symbol in file
>>>> pkgbuild: .CGB0.3612
>>>> ../glib/.libs/libglib-2.0.so
>>>> pkgbuild: .CGBA.3622
>>>> ../glib/.libs/libglib-2.0.so
>>>
>>> Looks like your libglib has references to these two symbols, which are
>>> remaining unresolved at the time you build your app.
>>>
>>> If you return to your libglib build, you can turn on ld(1)'s debugging
>>> and determine where these references are coming from.
>>>
>>> Set LD_OPTIONS=-Dsymbols,detail.
>>>
>>> You'll get (lots) of output on stderr defining which symbols come from
>>> which input files, and how they get resolved.
>>
>> those symbols are defined in pcre_compile.o but I can't figure out how
>> it gets there....
>
> Can't help with the source code I'm afraid, as I'm not familiar
> with any of it. I'd run the compilation of this file and capture
> the assembler output, that should tell you whee the symbol references
> are being generated. They are references, right? (nm shows UNDEF).
ok. Had to remember how to debug this.
so the compiler is generating this assembler from
glib-2.14.6/glib/pcre/pcre_compile.c
.CGBF.3627:
leaq .CGBA.3622(%rip),%r8 ;/ line : 2099
movslq -84(%rbp),%r9 ;/ line : 2099
addq -65536(%r8,%r9,8),%r8 ;/ line
: 2099
from this line
2097
2098 case ESC_W:
2099 return item <= 127 && (cd->ctypes[item] & ctype_word) != 0;
2100
and this assembler
.CGC1.3629:
leaq .CGB0.3612(%rip),%r8 ;/ line : 2021
movslq %r12d,%r9 ;/ line : 2021
addq -65536(%r8,%r9,8),%r8 ;/ line
: 2021
from this line
2019
2020 case OP_NOT_WORDCHAR:
2021 return next <= 127 && (cd->ctypes[next] & ctype_word) != 0;
2022
When I rewrote the condition statements to be like:
return ((item <= 127) && ((cd->ctypes[item] & ctype_word) != 0));
it didn't seem to make any difference. The symbols it is referencing
(.CGBA.3622,
.CGB0.3612 are not in the assembler listing, and I wouldn't expect to see an
external
reference since the variables in the condition state are local ones.
Once I dialed off the optimizations and rebuilt everything, it linked
correctly. So this
is looking to me like an optimization bug:
Original CFLAGS
CFLAGS = -Xc -xc99=%all -errshort=full -errfmt=error -errwarn=%none -s -xcsi
-xustr=ascii_utf16_ushort -features=extinl -xalias_level=std -mt
-D_XOPEN_SOURCE=600 -D_XPG6 -D_POSIX_C_SOURCE=200112L -D__XOPEN_OR_POSIX
-D_STRICT_STDC -D_STRICT_STDC__ -D_STDC_C99 -D_ISOC99_SOURCE -xF=%none
-xbuiltin=%all -xinline=%auto -xprefetch=auto
-xprefetch_auto_type=indirect_array_access -xprefetch_level=3 -xthreadvar=%all
-xipo=0 -xO3 -xregs=no%frameptr -xjobs=2 -KPIC -xrestrict=%all -xtarget=generic
-m64
Working CFLAGS
CFLAGS = -Xc -xc99=%all -errshort=full -errfmt=error -errwarn=%none -s -xcsi
-xustr=ascii_utf16_ushort -features=extinl -mt -D_XOPEN_SOURCE=600 -D_XPG6
-D_POSIX_C_SOURCE=200112L -D__XOPEN_OR_POSIX -D_STRICT_STDC -D_STRICT_STDC__
-D_STDC_C99 -D_ISOC99_SOURCE -xF=%none -xbuiltin=%all -xinline=%auto
-xprefetch=auto -xprefetch_level=3 -xthreadvar=%all -xipo=0 -xregs=no%frameptr
-KPIC -xrestrict=%all -xtarget=generic -m64
so removing -xjobs=2 -xO3 -xprefetch_auto_type=indirect_array_access -xalias=std
resulted in the libpcre.a library not having the symbols listed above.
--
This message posted from opensolaris.org
