This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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] | |
On 2/1/06, Richard Guenther <richard.guenther@gmail.com> wrote: > On 2/1/06, Paolo Bonzini <paolo.bonzini@lu.unisi.ch> wrote: > > > > > Is it intentional that these functions have global visibility and > > > interfere with functions declared and implemented by the system > > > libraries? If not, can they be compilied with hidden visibility? > > > > Yes (I originally tried to "see what happens if we use the glibc > > routines", then I shared the code with Richard who did the configury and > > the back-end patches. glibc people do not try to make life easy for > > people that use their code outside glibc, but I forgot to tell him about > > this...). > > Ok, so Darwin does not support symbol versioning? As then all these > conflicting symbols should be local. Originally Paolo added #pragma > visibility stuff which I removed during getting rid of all the C wrapper files. > I wonder if we can do some clever stuff with just using default hidden for > all files and appending an visibility attribute to the name defines. I can > work on this, but I didn't see any difference in exported symbols if using > it or not (probably due to the used linker script). Can you try the attached patch (it's not perfect as it misses to export some of the symbols due to the simple #define hack not working for them) and see if in principle it would solve the issue on Darwin? Thanks, Richard.
Attachment:
p8-6
Description: Binary data
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |