Created attachment 42035 [details]
Configure log

(In reply to comment #0)
> /opt/uClinux/bfin-uclinux/bin/bfin-uclinux-nm -B
> .libs/libtelepathy-glib-internal.a > _gen/abi.nm
> grep " [DT] " < _gen/abi.nm > _gen/abi.funcs
> cut -d" " -f3 < _gen/abi.funcs > _gen/abi.funcnames
> grep "^tp" < _gen/abi.funcnames > _gen/abi.tpfuncnames

What appears in telepathy-glib/_gen/abi.nm after attempting a build? (Attaching the whole file is probably easiest.)

Created attachment 42036 [details]
generated abi.nm

It looks as though your toolchain prepends an extra underscore to every symbol name (as seen by nm). I wonder how that interacts with symbol versioning...

(In reply to comment #4)
> It looks as though your toolchain prepends an extra underscore to every symbol
> name (as seen by nm). I wonder how that interacts with symbol versioning...

i compared the blackfin nm with a x86 one and it really has an extra _ at the start of every symbol.

i did not understand what do you mean with "how that interacts with symbol versioning", the problem is the toolchain im using, the way im using it...or the tpglib build system ?

The problem is that telepathy-glib is trying to do clever tricks with symbol versioning so we can detect accidental ABI breaks (and library users get better diagnostics if their telepathy-glib is too old), and I'm not sure how those interact with toolchains that prepend an underscore.

http://lists.gnupg.org/pipermail/gcrypt-devel/2010-June/001639.html seems to be basically the same problem.

One way we could work around this would be to try the symbol-versioning magic on a tiny library with known contents, and disable it if weird stuff is happening.

One workaround you could use to get a build would be to force the HAVE_LD_VERSION_SCRIPT conditional to be false.

(In reply to comment #6)
> The problem is that telepathy-glib is trying to do clever tricks with symbol
> versioning so we can detect accidental ABI breaks (and library users get better
> diagnostics if their telepathy-glib is too old), and I'm not sure how those
> interact with toolchains that prepend an underscore.
> 
> http://lists.gnupg.org/pipermail/gcrypt-devel/2010-June/001639.html seems to be
> basically the same problem.
> 
> One way we could work around this would be to try the symbol-versioning magic
> on a tiny library with known contents, and disable it if weird stuff is
> happening.

This would be great, it seems that any little difference on how the toolchain generates the symbols can break the build.

> 
> One workaround you could use to get a build would be to force the
> HAVE_LD_VERSION_SCRIPT conditional to be false.

i tried to do that and dont worked, i run a grep on the source dir to find where HAVE_LD_VERSION_SCRIPT is used, but grep didnt find it anywhere...are you sure this is used on tpglib too? on the libgcrypt it seems to exist, but not on tpglib.

im looking at the blackfin toolchain nm to see if i can found another workaround...maybe configure it to make an output that works.

thanks for the help Simon, as soon as i get a solution ill post it here.

(In reply to comment #7)
> (In reply to comment #6)
> > The problem is that telepathy-glib is trying to do clever tricks with symbol
> > versioning so we can detect accidental ABI breaks (and library users get better
> > diagnostics if their telepathy-glib is too old), and I'm not sure how those
> > interact with toolchains that prepend an underscore.
> > 
> > http://lists.gnupg.org/pipermail/gcrypt-devel/2010-June/001639.html seems to be
> > basically the same problem.
> > 
> > One way we could work around this would be to try the symbol-versioning magic
> > on a tiny library with known contents, and disable it if weird stuff is
> > happening.
> 
> This would be great, it seems that any little difference on how the toolchain
> generates the symbols can break the build.
> 
> > 
> > One workaround you could use to get a build would be to force the
> > HAVE_LD_VERSION_SCRIPT conditional to be false.
> 
> i tried to do that and dont worked, i run a grep on the source dir to find
> where HAVE_LD_VERSION_SCRIPT is used, but grep didnt find it anywhere...are you
> sure this is used on tpglib too? on the libgcrypt it seems to exist, but not on
> tpglib.

im sorry, im not sure what i did wrong before...but the HAVE_LD_VERSION_SCRIPT actually exists. 

i set it to 'no' on my environment, on the config.log it is set as:

HAVE_LD_VERSION_SCRIPT_FALSE='#'
HAVE_LD_VERSION_SCRIPT_TRUE=''

...but the build still fails on the same point.

/opt/uClinux/bfin-uclinux/bin/bfin-uclinux-nm -B .libs/libtelepathy-glib-internal.a > _gen/abi.nm
grep " [DT] " < _gen/abi.nm > _gen/abi.funcs
cut -d" " -f3 < _gen/abi.funcs > _gen/abi.funcnames
grep "^tp" < _gen/abi.funcnames > _gen/abi.tpfuncnames
make[3]: ** [_gen/abi.txt] Erro 1

> 
> im looking at the blackfin toolchain nm to see if i can found another
> workaround...maybe configure it to make an output that works.
> 
> thanks for the help Simon, as soon as i get a solution ill post it here.

(In reply to comment #8)
> i set it to 'no' on my environment, on the config.log it is set as:
> 
> HAVE_LD_VERSION_SCRIPT_FALSE='#'
> HAVE_LD_VERSION_SCRIPT_TRUE=''

That means it didn't work. configure probably doesn't look at your environment but does some check instead. An AC_DEFINE in configure.ac is probably what you want.

(In reply to comment #9)
> (In reply to comment #8)
> > i set it to 'no' on my environment, on the config.log it is set as:
> > 
> > HAVE_LD_VERSION_SCRIPT_FALSE='#'
> > HAVE_LD_VERSION_SCRIPT_TRUE=''
> 
> That means it didn't work. configure probably doesn't look at your environment
> but does some check instead.

i thought that a HAVE_LD_VERSION_SCRIPT_FALSE='#' would mean that the FALSE option is enable, while a HAVE_LD_VERSION_SCRIPT_TRUE with an empty '' means not enabled, not very used with this config stuff :-).

> An AC_DEFINE in configure.ac is probably what you
> want.

im going to take a look on it.

Thanks for the help Emilio.

Taking a look at configure.ac/Makefile.am/abi.am ...well a lot of stuff, it seems that i cant configure HAVE_LD_VERSION_SCRIPT, the generated configure will check if the compiler support it and will enable or disable it automatically, i didn't find anything to disable it.

i could easily force it to bypass all this on configure.ac and compile, but i was thinking on fix that better. If I'm right and there is no way to manually disable this, what do you guys think about creating an option to disable it on configure.ac ? i could do the changes, test it and make a patch.

or i could mess around a little more with the grep logic that breaks because of the extra "_" appended at the start of the symbols.

not sure about the better option to solve the problem.

(In reply to comment #11)
> Taking a look at configure.ac/Makefile.am/abi.am ...well a lot of stuff, it
> seems that i cant configure HAVE_LD_VERSION_SCRIPT, the generated configure
> will check if the compiler support it and will enable or disable it
> automatically, i didn't find anything to disable it.
> 
> i could easily force it to bypass all this on configure.ac and compile, but i
> was thinking on fix that better. If I'm right and there is no way to manually
> disable this, what do you guys think about creating an option to disable it on
> configure.ac ? i could do the changes, test it and make a patch.
> 
> or i could mess around a little more with the grep logic that breaks because of
> the extra "_" appended at the start of the symbols.
> 
> not sure about the better option to solve the problem.


A better solution has appeared :-).
bfin-uclinux-nm was being called with a -B, changing the nm call to:

bfin-uclinux-nm --demangle=gnu

fixes the problem, the default -B is the same as --demangle=bsd.
on way to set this is by calling:

export NM="bfin-uclinux-nm --demangle=gnu"

before compiling, overriding the toolchain default -B.

thanks for all the help.

Best regards,
Tiago Katcipis