Restricting symbol binding within shared object

Restricting symbol binding within shared object

[Arindam]

Hi,

I am using a Linux 2.6 (SuSE 9) build machine with gcc 3.3.3 installed.

I have two shared libraries linked to an executable. The executable
calls two functions - say bar1() in one shared lib and bar2() in
another. It so happens that both bar1 and bar2 internally call a
function say foo(). There is a different version of foo defined in
each shared object with same signature but different internal
implementation. It so happens that when both shared libs are linked to
my executable, both bar1 and bar2's calls resolve to the foo defined
in shared object 1. I am trying to figure out a way to resolve each
call "locally" within the shared object. I tried the -Bsymbolic switch
for the linker but it did not work - perhaps because this is C++ code,
although the functions in question are declared with C linkage (extern
"C").

Please help!

- Arindam


PS: I tried a round-about way of restricting which symbols are
exported from each shared object - using a linker version script. I
hid the "foo" symbol from the shared objects and it worked the way I
wanted. However, this is not an acceptable or convenient solution.

-- 
-----------------
A. It messes the natural order in which we read.
Q. What's with it?
A. Top-Posting,
Q. What is the most annoying thing on emails and posts?

special comments handling in the C compiler

[Tim Wang]

Hi,

I want to modify the c compiler so that the comments aren't stripped but 
stored and printed out later onto the assembly output as comments.  Which 
files or more specifically which functions should I start to modifying?  
Right now I've just started digging through the gcc sources.  I am currently 
reading through c-parser.c.   Any help in pointing me towards the right 
direction would greatly appreicated.  Thank you in advance.   

Regards,

Tim Wang

extern "C" From command line

[Seyran Avanesyan]

Hi,

Is there any way to make exported function names unmangled without using
extern "C"? 

I'm compiling c++ file to a dll. Exported functions doesn't have extern
"C" specified for them, so their names got mangled.
The file cannot be edited.

gcc -x c++ source.cpp -o source.o 	
gcc -shared -o source.dll other_source.o source.o 

If I put required names into .def file but compile as c++ file, because
of mangling I got errors: "Can not export ZZZZ: symbol not defined"


Thanks,
Seyran

Re: extern "C" From command line

[Brian Dessent]

Seyran Avanesyan wrote:

> Hi,

Please don't hijack threads; start a new thread.  Changing the subject
line does not accomplish this.  The mailing list archives on the gcc
website and any threaded email client will show your message as a reply
in a completely unrelated thread.

> Is there any way to make exported function names unmangled without using
> extern "C"?
> 
> I'm compiling c++ file to a dll. Exported functions doesn't have extern
> "C" specified for them, so their names got mangled.
> The file cannot be edited.
> 
> gcc -x c++ source.cpp -o source.o
> gcc -shared -o source.dll other_source.o source.o
> 
> If I put required names into .def file but compile as c++ file, because
> of mangling I got errors: "Can not export ZZZZ: symbol not defined"

The mangling is there for a reason.  If you exported a function with C++
linkage but without its name mangled then it's very likely that you
could call it from a compiler with a different C++ ABI, such as MSVC,
and that would fail.  Mangling prevents this, because it requires that
to call the function you have a compiler with compatible ABI.

If your complaint is simply that you don't want to put mangled names in
the .def file, then I must ask: why use a .def file at all?  It's
usually not needed.  The GNU linker has auto-export enabled by default
which causes all symbols to be exported if __declspec(dllexport) is not
used anywhere.  And if __declspec(dllexport) is used, then the source
itself already controls what functions to be exported so the .def file
is extraneous.

Brian

RE: extern "C" From command line

[Seyran Avanesyan]

Brian Dessent wrote:

> Please don't hijack threads; start a new thread.  

Thanks for correcting me. 

> The mangling is there for a reason.  If you exported a function with
> C++
> linkage but without its name mangled then it's very likely that you
> could call it from a compiler with a different C++ ABI, such as MSVC,
> and that would fail.  Mangling prevents this, because it requires that
> to call the function you have a compiler with compatible ABI.

The functions are going to be exported from a Dll, which is going to be
done using MinGW. Is that still requires that client of that Dll be
compiled with MinGW? 

> If your complaint is simply that you don't want to put mangled names
in
> the .def file, then I must ask: why use a .def file at all?  It's
> usually not needed.  The GNU linker has auto-export enabled by default
> which causes all symbols to be exported if __declspec(dllexport) is
not
> used anywhere.  And if __declspec(dllexport) is used, then the source
> itself already controls what functions to be exported so the .def file
> is extraneous.

gcc -x c++ source.cpp -o source.o
gcc -shared -o source.dll my_source.o source.o

I'm exporting just two functions from "my_source.o" (which I have access
to, and they have __declspec(dllexport) and extern "C").
There are many other global functions in "my_source.o" which is used
from "source.o", but not need to be exported from the resulting Dll.

I needed .def file to export all global functions from "source.o" to not
use -export-all feature (because it will export all globals from both
modules regardless of __declspecs.)
And I'm getting this .def file by using dlltool (MinGW component.)

The problem is I need to MinGW compile a Dll as C++ not as C, and call
exported functions from MSVC compiled application. 


Thanks,

Seyran

Re: extern "C" From command line

[Brian Dessent]

Seyran Avanesyan wrote:

> The functions are going to be exported from a Dll, which is going to be
> done using MinGW. Is that still requires that client of that Dll be
> compiled with MinGW?

If they have C++ linkage then they need to be called with a C++ compiler
with compatible ABI.  If you want to mix compilers with different C++
ABIs (such as gcc and MSVC) then you need to use C linkage.

> The problem is I need to MinGW compile a Dll as C++ not as C, and call
> exported functions from MSVC compiled application.

Then you need C linkage, which means you have no choice but to enclose
the code in "extern C" (or compile it with a C compiler of course.)  If
you really can't modify the source.cpp file then I still don't see why
you can't do something like:

extern "C" {
#include "source.cpp"
}

Brian

RE: extern "C" From command line

[Seyran Avanesyan]

> Then you need C linkage, which means you have no choice but to enclose
> the code in "extern C" (or compile it with a C compiler of course.)
If
> you really can't modify the source.cpp file then I still don't see why
> you can't do something like:
> 
> extern "C" {
> #include "source.cpp"
> }

Well, I can't do that because source.cpp allowed to contain #include-s.
(Of course I can parse source.cpp and create modified_source.cpp. Just
need to preprocess, then use yacc/lex or Spirit C-grammar parser...)

I can also write my own, simplified grammar parser for source.cpp (since
source.cpp is using C syntax).

But I just tried to compile with "-x c++" with extern "C" in souce.cpp
(experimentally added that manually), and when I tried to call it from
MSVC app I've got a crash.

64-bit gcc

[Seyran Avanesyan]

Hi,

Which version of gcc should I use to compile 64-bit targets.
I used gcc 3.4.5. With -m64 switch I'm getting this message:

source_file.c:1: sorry, unimplemented: 64-bit mode not compiled in


Thanks,

Seyran

Re: 64-bit gcc

[Brian Dessent]

Seyran Avanesyan wrote:

> Which version of gcc should I use to compile 64-bit targets.
> I used gcc 3.4.5. With -m64 switch I'm getting this message:
> 
> source_file.c:1: sorry, unimplemented: 64-bit mode not compiled in

This is an incomplete question.  You need to specify what target you're
talking about.  I'm assuming you're referring to the MinGW target.  If
that is true, then the MinGW project currently only supports 32 bit
Windows.  There is a separate fork of the MinGW project supporting
Windows x64: <http://sourceforge.net/projects/mingw-w64>.  This is quite
alpha, as support for Windows x64 in gcc is relatively new and still
under active development.

Brian

RE: 64-bit gcc

[Seyran Avanesyan]

Thanks for reply. 

Yes, the target was Windows, and the separate fork is in active
development, this is why I was looking for earlier versions.
According to some posts gcc3.2.0 should do that. But it isn't, so I was
wondering if instead of downloading binaries I might have to compile
GCC/MinGW myself to get that working.

And I'm also interested in compiling 64-bit targets using original GCC
(planning to move Linux soon). 

Seyran

-----Original Message-----
From: Brian Dessent [mailto:brian@dessent.net] 
Sent: Thursday, August 21, 2008 7:12 PM
To: Seyran Avanesyan
Cc: gcc-help@gcc.gnu.org
Subject: Re: 64-bit gcc

Seyran Avanesyan wrote:

> Which version of gcc should I use to compile 64-bit targets.
> I used gcc 3.4.5. With -m64 switch I'm getting this message:
> 
> source_file.c:1: sorry, unimplemented: 64-bit mode not compiled in

This is an incomplete question.  You need to specify what target you're
talking about.  I'm assuming you're referring to the MinGW target.  If
that is true, then the MinGW project currently only supports 32 bit
Windows.  There is a separate fork of the MinGW project supporting
Windows x64: <http://sourceforge.net/projects/mingw-w64>.  This is quite
alpha, as support for Windows x64 in gcc is relatively new and still
under active development.

Brian

Re: 64-bit gcc

[Brian Dessent]

Seyran Avanesyan wrote:

> Yes, the target was Windows, and the separate fork is in active
> development, this is why I was looking for earlier versions.
> According to some posts gcc3.2.0 should do that. But it isn't, so I was
> wondering if instead of downloading binaries I might have to compile
> GCC/MinGW myself to get that working.

x86_64 support for *Linux* was in gcc 3.2.  Not Windows x64.  They are
very different targets even though the underlying hardware might be the
same.

> And I'm also interested in compiling 64-bit targets using original GCC
> (planning to move Linux soon).

What do you mean by "original gcc"? 

Brian

RE: 64-bit gcc

[Seyran Avanesyan]

> What do you mean by "original gcc"?

By "original gcc" I meant not the one in MinGW (or any other ports of
GCC). My understanding is that GCC was created for Linux/Unix systems in
first place.

Re: 64-bit gcc

[Brian Dessent]

Seyran Avanesyan wrote:

> > What do you mean by "original gcc"?
> 
> By "original gcc" I meant not the one in MinGW (or any other ports of
> GCC). My understanding is that GCC was created for Linux/Unix systems in
> first place.

You're making a distinction where one does not exist.  gcc is gcc.  gcc
currently supports something like three dozen architectures, all from a
single code base.  (And if you count OS variations[1] and bare metal
systems the number of distinct targets is in the hundreds.)  There is no
"linux gcc version" or "windows gcc version", it's all the same codebase
built with different options or in different environments.

Some ports might have some local patches that are not in FSF gcc (but I
don't think mingw-w64 has any) but those are usually to correct broken
behavior in certain corner cases so they are things you want.

Brian

[1] For example, for the x86 architecture alone: Linux, Darwin/OS X,
Cygwin, MinGW, {Free,Net,Open}BSD, RTEMS, Vxworks, bare metal, etc.

Re: 64-bit gcc

[NightStrike]

On 8/22/08, Brian Dessent <brian@dessent.net> wrote:
> Some ports might have some local patches that are not in FSF gcc (but I
> don't think mingw-w64 has any) but those are usually to correct broken
> behavior in certain corner cases so they are things you want.

Correct, we don't have any.  We push everything upstream.

RE: 64-bit gcc

[Seyran Avanesyan]

 
> You're making a distinction where one does not exist.  gcc is gcc.
gcc
> currently supports something like three dozen architectures, all from
a
> single code base.  (And if you count OS variations[1] and bare metal
> systems the number of distinct targets is in the hundreds.)  There is
> no
> "linux gcc version" or "windows gcc version", it's all the same
> codebase
> built with different options or in different environments.
> 
> Some ports might have some local patches that are not in FSF gcc (but
I
> don't think mingw-w64 has any) but those are usually to correct broken
> behavior in certain corner cases so they are things you want.
> 
> Brian
> 
> [1] For example, for the x86 architecture alone: Linux, Darwin/OS X,
> Cygwin, MinGW, {Free,Net,Open}BSD, RTEMS, Vxworks, bare metal, etc.

Does it mean that gcc4.4.0 in mingw-w64 is more like a branch which some
time is going to be merged with main source code, then a fork, which
will live with its own life?

Re: 64-bit gcc

[Brian Dessent]

Seyran Avanesyan wrote:

> Does it mean that gcc4.4.0 in mingw-w64 is more like a branch which some
> time is going to be merged with main source code, then a fork, which
> will live with its own life?

No, it's a straight build of unmodified code from the gcc.gnu.org
subversion repository.

The reason that you need projects like mingw-w64 or MinGW or Cygwin is
because gcc is just a compiler.  In isolation it is nearly useless
unless you intend to use a freestanding environment (which you are
almost certainly not doing.)  gcc does not include an assembler, or a
linker, or a C library/headers, etc.  You need the context of a complete
target in order to do real work.

In the case of the common Windows ports this means you have to choose
whether you want to use the Cygwin libc runtime or the Microsoft libc
runtime, and add the headers and libraries of the chosen runtime, as
well as various other support files like the crt*.o startup objects. 
Projects like MinGW and Cygwin coordinate this integration of compiler +
linker + assembler + runtime + headers, much in the same way that Linux
distributions combine a lot of disparate packages to make something
useful.

Brian

Re: 64-bit gcc

[NightStrike]

On 8/22/08, Seyran Avanesyan <seyran.avanesyan@tanner.com> wrote:
> Thanks for reply.
>
> Yes, the target was Windows, and the separate fork is in active
> development, this is why I was looking for earlier versions.
> According to some posts gcc3.2.0 should do that. But it isn't, so I was
> wondering if instead of downloading binaries I might have to compile
> GCC/MinGW myself to get that working.

The mingw-w64 project that Brian linked you to can generate 32-bit as
well as 64-bit binaries.  You can cross compile from 5 different
systems, or you can compile natively.

The current version is stable enough to compile several
high-visibility projects, including wxwidgets, vlc, ffmpeg, and more.
If you need help with anything, post on the mailing list or forum for
that project.

RE: 64-bit gcc

[Seyran Avanesyan]

Thanks a lot.

> -----Original Message-----
> From: NightStrike [mailto:nightstrike@gmail.com]
> Sent: Friday, August 22, 2008 7:00 PM
> To: Seyran Avanesyan
> Cc: brian@dessent.net; gcc-help@gcc.gnu.org
> Subject: Re: 64-bit gcc
> 
> On 8/22/08, Seyran Avanesyan <seyran.avanesyan@tanner.com> wrote:
> > Thanks for reply.
> >
> > Yes, the target was Windows, and the separate fork is in active
> > development, this is why I was looking for earlier versions.
> > According to some posts gcc3.2.0 should do that. But it isn't, so I
> was
> > wondering if instead of downloading binaries I might have to compile
> > GCC/MinGW myself to get that working.
> 
> The mingw-w64 project that Brian linked you to can generate 32-bit as
> well as 64-bit binaries.  You can cross compile from 5 different
> systems, or you can compile natively.
> 
> The current version is stable enough to compile several
> high-visibility projects, including wxwidgets, vlc, ffmpeg, and more.
> If you need help with anything, post on the mailing list or forum for
> that project.

Re: Restricting symbol binding within shared object

[Ian Lance Taylor]

Arindam <arindam.mukerjee@gmail.com> writes:

> I have two shared libraries linked to an executable. The executable
> calls two functions - say bar1() in one shared lib and bar2() in
> another. It so happens that both bar1 and bar2 internally call a
> function say foo(). There is a different version of foo defined in
> each shared object with same signature but different internal
> implementation. It so happens that when both shared libs are linked to
> my executable, both bar1 and bar2's calls resolve to the foo defined
> in shared object 1. I am trying to figure out a way to resolve each
> call "locally" within the shared object. I tried the -Bsymbolic switch
> for the linker but it did not work - perhaps because this is C++ code,
> although the functions in question are declared with C linkage (extern
> "C").

-Bsymbolic should have worked.  Note that you have to use it when
linking the shared libraries.

With a newer version of gcc you can use visibility attributes.  That
is probably your best approach here.

http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#Function-Attributes

search for
    visibility ("visibility_type")

Ian

Re: Restricting symbol binding within shared object

[Arindam]

On 8/19/08, Ian Lance Taylor <iant@google.com> wrote:
> Arindam <arindam.mukerjee@gmail.com> writes:
>
> > I have two shared libraries linked to an executable. The executable
> > calls two functions - say bar1() in one shared lib and bar2() in
> > another. It so happens that both bar1 and bar2 internally call a
> > function say foo(). There is a different version of foo defined in
> > each shared object with same signature but different internal
> > implementation. It so happens that when both shared libs are linked to
> > my executable, both bar1 and bar2's calls resolve to the foo defined
> > in shared object 1. I am trying to figure out a way to resolve each
> > call "locally" within the shared object. I tried the -Bsymbolic switch
> > for the linker but it did not work - perhaps because this is C++ code,
> > although the functions in question are declared with C linkage (extern
> > "C").
>
> -Bsymbolic should have worked.  Note that you have to use it when
> linking the shared libraries.

It actually does work. My mistake - I used -symbolic with g++ instead,
expecting it to translate to -Bsymbolic for the linker. I later used
-Wl,-Bsymbolic and that worked for me.

>
> With a newer version of gcc you can use visibility attributes.  That
> is probably your best approach here.
>
> http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#Function-Attributes
>
> search for
>    visibility ("visibility_type")
>

Cool ... so this mimics the Windows __declspec(dllexport) kind of
declarations. I know that newer versions of Sun Studio have
essentially the same functionality (albeit with a less obnoxious
syntax). I need to figure out if aCC on HP-UX has something similar
too. Is this a new thing on ELF format?

- Arindam

Re: Restricting symbol binding within shared object

[Ian Lance Taylor]

Arindam <arindam.mukerjee@gmail.com> writes:

>> With a newer version of gcc you can use visibility attributes.  That
>> is probably your best approach here.
>>
>> http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#Function-Attributes
>>
>> search for
>>    visibility ("visibility_type")
>>
>
> Cool ... so this mimics the Windows __declspec(dllexport) kind of
> declarations. I know that newer versions of Sun Studio have
> essentially the same functionality (albeit with a less obnoxious
> syntax). I need to figure out if aCC on HP-UX has something similar
> too. Is this a new thing on ELF format?

It works for Mach-O (used on Mac OS) as well.

Ian