headers
Chris Miller | 1 Mar 2009 02:51

how to NOT export symbols in statically linked 3rd party shared libs

Hi all,

I have the following problem:

I have created a shared lib and want to make sure I only export those
symbols that should be accessible from external.
I manage to do that fine with "#pragma GCC visibility"  switches for all
my "own" symbols.
However my lib also statically links OpenSSL and the linker exports all
symbols in libssl too.

That is a problem because it creates a symbol collision - so how can I
keep the linker from also exporting the symbols of libs (*.a) statically
linked to my shared lib?

I appreciate any comment/hint!

Thanks a bunch!

Chris
Permalink | Reply | 6 comments |
headers
Andrew Haley | 1 Mar 2009 12:47
Picon
Favicon

Re: how to NOT export symbols in statically linked 3rd party shared libs

Chris Miller wrote:

> I have created a shared lib and want to make sure I only export those
> symbols that should be accessible from external.
> I manage to do that fine with "#pragma GCC visibility"  switches for all
> my "own" symbols.
> However my lib also statically links OpenSSL and the linker exports all
> symbols in libssl too.
> 
> That is a problem because it creates a symbol collision - so how can I
> keep the linker from also exporting the symbols of libs (*.a) statically
> linked to my shared lib?

You'll need to write a linker script.  There are plenty of examples around,
some even in the gcc sources, or you can ask the binutils list.

Andrew.
Permalink | Reply | 5 comments |
headers
Chris Miller | 1 Mar 2009 13:29

Re: how to NOT export symbols in statically linked 3rd party shared libs

Thank you, Andrew,

actually, I figured that out after I sent this question to the ML.
However, the next question, which seems to be the core of the problem
arises:
What I really want to make sure is that at runtime, local symbols (the
ones not exported) will have precedence over exported (colliding)
symbols of other libs.

Is that the case?

Thanks again,

Chris

Andrew Haley schrieb:
> Chris Miller wrote:
>
>   
>> I have created a shared lib and want to make sure I only export those
>> symbols that should be accessible from external.
>> I manage to do that fine with "#pragma GCC visibility"  switches for all
>> my "own" symbols.
>> However my lib also statically links OpenSSL and the linker exports all
>> symbols in libssl too.
>>
>> That is a problem because it creates a symbol collision - so how can I
>> keep the linker from also exporting the symbols of libs (*.a) statically
>> linked to my shared lib?
>>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andrew Haley | 1 Mar 2009 14:49
Picon
Favicon

Re: how to NOT export symbols in statically linked 3rd party shared libs

Chris Miller wrote:
> Thank you, Andrew,
> 
> actually, I figured that out after I sent this question to the ML.
> However, the next question, which seems to be the core of the problem
> arises:
> What I really want to make sure is that at runtime, local symbols (the
> ones not exported) will have precedence over exported (colliding)
> symbols of other libs.
> 
> Is that the case?

If and only if you use -Bsymbolic when linking, yes.  However,
-Bsymbolic is not without problems: one of the guarantees of C is that
&symbol always returns the same result, no matter who is asking.  All
manner of things can break if this isn't true.

Also, if you use -Bsymbolic in a shared library you also should link
all executables with -fPIC.  This is needed because -Bsymbolic breaks
copy relocations in an executable so that it ends up with a private
copy of all the statically-allocated data in shared libraries.  All
hell then breaks loose, as you can imagine.  :-)  Compiling the
executable -fPIC ensures that there are no copy relocs created.

Andrew.
Permalink | Reply | 3 comments |
headers
Chris Miller | 1 Mar 2009 15:40

Re: how to NOT export symbols in statically linked 3rd party shared libs

Thank you Andrew!

That helps - a lot!!

Chris

Andrew Haley schrieb:
> Chris Miller wrote:
>   
>> Thank you, Andrew,
>>
>> actually, I figured that out after I sent this question to the ML.
>> However, the next question, which seems to be the core of the problem
>> arises:
>> What I really want to make sure is that at runtime, local symbols (the
>> ones not exported) will have precedence over exported (colliding)
>> symbols of other libs.
>>
>> Is that the case?
>>     
>
> If and only if you use -Bsymbolic when linking, yes.  However,
> -Bsymbolic is not without problems: one of the guarantees of C is that
> &symbol always returns the same result, no matter who is asking.  All
> manner of things can break if this isn't true.
>
> Also, if you use -Bsymbolic in a shared library you also should link
> all executables with -fPIC.  This is needed because -Bsymbolic breaks
> copy relocations in an executable so that it ends up with a private
> copy of all the statically-allocated data in shared libraries.  All
(Continue reading)

Permalink | Reply | 0 comments |
headers
lehe | 1 Mar 2009 19:06
Picon
Favicon

using -ggdb3 and -O3 simultaneously


Hi,
I was wondering what is the purpose of using -ggdb3 and -O3 simultaneously
for gcc? One is for debug and the other is for optimization. Is this to
debug the optimized code? Can anyone point me to some reference explaining
this well? Thanks!
--

-- 
View this message in context: http://www.nabble.com/using--ggdb3-and--O3-simultaneously-tp22275813p22275813.html
Sent from the gcc - Help mailing list archive at Nabble.com.
Permalink | Reply | 1 comment |
headers
Edek P. | 1 Mar 2009 19:14
Picon

Snapshot g++, -frepo and collect2 error (symbol in .rpo but not compiled)

Hi,

sorry for everything ;), I just started playing with compiling gcc.

I have Fedora 8, I have some software I'm writing, I'm trying to switch to gcc 4.4.x because of some previous
bugs in gcc.
Anyway, I compiled gcc and g++, here is the version dump, it was compiled with some optimizing flags for my cpu

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.4-20090227/configure --prefix=/home/s1/soft/gcc/soft_b2/
--program-suffix=-4.4-20090227-b2 --with-mpfr=/home/s1/soft/gcc/soft_b2/
--with-ppl=/home/s1/soft/gcc/soft_b2/ 
--with-cloog=/home/s1/soft/gcc/soft_b2/ --with-decimal-float --enable-libssp
--enable-threads=posix --disable-bootstrap
Thread model: posix
gcc version 4.4.0 20090227 (experimental) (GCC)

I didn't run the gcc tests (make check) yet. I did "make check" the prerequisites. This build was compiled
with previous build (same snapshot) compiled with stock gcc (Fedora 4.1.2 version).

What happens when I compile some templated stuff to a DSO:

collect2:

'_ZN4dogs4util3xml8TXmlBaseINS1_12TSimpleTypesISbIwSt11char_traitsIwESaIwEEEENS1_6xerces16TNamespaceXercesIS8_EENS9_14TElementXercesIS8_NS9_11TTextXercesIS8_EESB_NS9_16TAttributeXercesIS8_SB_SE_EEEEE14getRootElementEv' 
was assigned to
'/home/s1/tmp/dogs_svn/imported/trunk/build/obj/util/impl/xml/XmlImplementationFactory.rpo',
but was not defined during recompilation, or vice versa
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin P. Fleming | 1 Mar 2009 19:18
Favicon
Gravatar

Re: how to NOT export symbols in statically linked 3rd party shared libs

Andrew Haley wrote:
> Chris Miller wrote:
>> Thank you, Andrew,
>>
>> actually, I figured that out after I sent this question to the ML.
>> However, the next question, which seems to be the core of the problem
>> arises:
>> What I really want to make sure is that at runtime, local symbols (the
>> ones not exported) will have precedence over exported (colliding)
>> symbols of other libs.
>>
>> Is that the case?

Forgive what may be a basic (and mostly off-topic) question, but is
there any way to get GNU ld to output the linker script it generated
internally (sort of) during a normal link, so we can use that as a
starting point?

--

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming <at> digium.com
Check us out at www.digium.com & www.asterisk.org
Permalink | Reply | 1 comment |
headers
Andrew Haley | 1 Mar 2009 20:01
Picon
Favicon

Re: how to NOT export symbols in statically linked 3rd party shared libs

Kevin P. Fleming wrote:

> Forgive what may be a basic (and mostly off-topic) question, but is
> there any way to get GNU ld to output the linker script it generated
> internally (sort of) during a normal link, so we can use that as a
> starting point?

Yeah, [1] but you really don't want to do that if you're just controlling
exports.  The linker script to do that is very cut-down, not a full
linker script.

Look at gcc/config/i386/libgcc-glibc.ver

Andrew.

[1] man ld:

       --dll-verbose
       --verbose
           Display the version number for ld and list the linker emulations
           supported.  Display which input files can and cannot be opened.
           Display the linker script being used by the linker.
Permalink | Reply | 0 comments |
headers
Qinghai Zhang | 1 Mar 2009 22:21
Favicon

gcc 4.2.4 bootstrap failure

Dir Sir/Madam,

    I am trying to bootstrap gcc 4.2.4 on openSUSE 11.1 since some library I currently use do not support gcc
4.3.x yet. My machine is AMD dual Opetron 8222 socket F. 

    The configure command I used was:
----------------------------------------------------------------
 ../gcc-4.2.4/configure --prefix=/home/tsinghai/install/HyPAM/gcc-4.2.4 --enable-language=c,c++,fortran
 ---------------------------------------------------------------

    `make bootstrap' finally generated the following:
-------------------------------------------------------------------------------------------------------------------------
  make[5]: Entering directory `/home/tsinghai/tmp/hypamInstall/gccObj/gcc'
/home/tsinghai/tmp/hypamInstall/gccObj/./gcc/xgcc
-B/home/tsinghai/tmp/hypamInstall/gccObj/./gcc/
-B/home/tsinghai/install/HyPAM/gcc-4.2.4/x86_64-unknown-linux-gnu/bin/
-B/home/tsinghai/install/HyPAM/gcc-4.2.4/x86_64-unknown-linux-gnu/lib/ -isystem
/home/tsinghai/install/HyPAM/gcc-4.2.4/x86_64-unknown-linux-gnu/include -isystem
/home/tsinghai/install/HyPAM/gcc-4.2.4/x86_64-unknown-linux-gnu/sys-include -O2 -O2 -g -O2 
-DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -I. -I32 -I../../gcc-4.2.4/gcc
-I../../gcc-4.2.4/gcc/32 -I../../gcc-4.2.4/gcc/../include
-I../../gcc-4.2.4/gcc/../libcpp/include  -I../../gcc-4.2.4/gcc/../libdecnumber
-I../libdecnumber -m32 -g0 -finhibit-size-directive -fno-inline-functions -fno-exception
 s -fno-zero-initialized-in-bss -fno-toplevel-reorder   -fno-omit-frame-pointer
-fno-asynchronous-unwind-tables \
	  -c ../../gcc-4.2.4/gcc/crtstuff.c -DCRT_BEGIN \
	  -o 32/crtbegin.o
In file included from /usr/include/features.h:354,
                 from /usr/include/stdio.h:28,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane