This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Linkfailures on amd64 with -fvisibility-inlines-hidden and the libstdc++ headers or symbols


I currently experiment with the new -fvisibility options for gcc-3.4
and gcc-4.0. And i ran into problems with the basic_string headers.

If i use std::string within a library that gets compiled with 
-fvisibility-inlines-hidden, ld is unable to link. 

#include <string> 
int some_function( std::string const& do_something ) __attribute__ ((visibility("default")));

int some_function( std::string const& do_something ) 
  std::string another_string;
  return 0;

g++ -fPIC -fvisibility=hidden -fvisibility-inlines-hidden lib.cpp -c
g++ -shared -fPIC  -fvisibility=hidden -fvisibility-inlines-hidden lib.o -o
lib.o: relocation R_X86_64_PC32 against `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string()@@GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC
final link failed: Bad value
collect2: ld returned 1 exit status

If i do not use the default constructor of std::string, it works fine. I
noticed similar problems with the destructor and the std::allocator. It
seems like a bad idea to use -fvisibility-inlines-hidden at all. The
problem vanishes if I add __attribute__ ((visibility("default"))) to the 
symbols in the string headers. Other inline methods of my own code are not 
affected, this happens only in the libstdc++ headers. 

I noticed other parties having the same problem:

Is this a gcc bug? Or maybe some problem that occurs because the gcc-extern-export 
and the new visibility options collide?

Andreas Pokorny

Attachment: pgp00000.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]