[lsb-discuss] LSB Porting errors
Wichmann, Mats D
mats.d.wichmann at intel.com
Wed Sep 13 09:14:36 PDT 2006
Reading further....
> Other unknown symbols are things
>like __moddi3 which are generated from the compiler for math
>stuff. Shouldn't those be part of the LSB standard?
>
>Are the any ideas what could cause such errors? Might there be
>any problem with my build environment setup? I can create small
>sample "hello world" lsb application without any problems.
>If someone needs more information I will of course provide it to you.
These will be supplied by the final link edit from libgcc.a.
As they are statically linked, they do not form part of the
shared-library interface set specified by the LSB. gcc will
automagically link this in in the default (non-LSB) situation,
so lsbcc makes sure that happens also. Unfortunately, archk
doesn't know about that - that's basically the reason archk
is marked non-production, it doesn't at the moment have a
way to know about things that will be resolved later, at
the time of the final link-edit.
===
In your message you say two separate things which lead to
a question:
""tfprint" links to these shared libraries which will all
distributed with the final product. So there should
be no problem with shared linking according to LSB and
static linking should not be necessary."
and:
"The command libarchk -A /usr/local/lib/libtbarcode2.a
returned the results shown in the screenshot
lsbarchk_error.jpg"
Does this mean you're actually doing static linking?
Just to make sure, you know you can instruct lsbcc that
your libraries are okay to link dynamically? You want the
LSBCC_SHAREDLIBS environment variable for this - see
the lsbcc manpage.
Cheers,
Mats
More information about the lsb-discuss
mailing list