cygwin patch review

[Benjamin Kosnik <bkoz at redhat dot com>]

From older mail thread:

>> I do have some concerns about this patch, and would like to be able
>> to  try
>> an alternate approach (based on -fvisibility) and scope the symbol
>> versioning situation. Thus my interest in replicating your
>> testresults, so I
>> can use it as a baseline.  

> Wouldn't this still require the same kind of markup anyway?  

No. There is already visibility markup on libstdc++ headers for this.
You can just put the attribute visibility bits on namespace std, and be
done with it.

Here, from include/bits/c++config.h:

# define _GLIBCXX_BEGIN_NAMESPACE(X) namespace X
_GLIBCXX_VISIBILITY_ATTR(default)


This should work out of the box... and remove the need for partial
attribute-ization. I'm concerned with what is and what is not annotated
with dllimport. What's the criteria here?

My best guess:
1) stuff with _GLIBCXX_EXTERN_TEMPLATE
2) exception classes
3) io classes

What about the allocators, containers, TR1 exceptions, C++0x exceptions,
etc? Can you provide some insight on how the libstdc++ maintainers will
choose how to deploy _GLIBCXX_IMPORT?

Looks like darwin started using this around 2006-12-02, which may be
after the design for cywin was established.

>Only on ELF
>platforms you'd define _GLIBCXX_IMPORT to __attribute__ ((visibility
>("default"))) while compiling libstdc++ and use -fvisibility=hidden?  

No. You're just using -fvisibility=hidden and maybe
-fvisibility-inlines-hidden, although I'm not sure what the status is on
this flag.

Everything else is done via attributes on namespace std. I don't know if
attribute (dllimport) works on namespace std. Does it? That might be
another option.

After talking to Jason for a bit it looks like dllimport on namespace
std may not work right now. I think the visibility attributes are the
only things that work on namespaces. There is certainly no reason why
other attributes couldn't work.

> Were you
>planning to make -fvisibility work in some way on windows, or just use
>#definery to use dllimport/dllexport there?  

Look at what Darwin is doing here.

Does visibility not work on cygwin? More details about this option on PE
hosts please. It is supposed to work.

My other questions for you, after some poking around:

1) What would it take to map the baseline_symbols.txt file to a suitable
.def file to control exports on cygwin? Are there known issues and if
so, what?

2) operator new/delete replaceable signature stuff looks cool. However,
isn't this different behavior than with the microsoft runtimes, which
don't support this? FWIW, I thought intrapostion didn't work on that
platform. To me, it looks like you've solved this for the GNU
toolchain. Yay. This part of your patch is ok with me for sure. But
where to note this kind of usage stuff so that when people go mad
trying to debug some subtle thing, we can point to a web page and claim
not guilty? I am not even quite sure that there are new/delete
intraposition tests in the testsuite.

3) How are you documenting the static/shared libgcc/libstdc++ issues? It
seems that there is some subtlety involved with these flags and the DLL
version of libstdc++. (No ideas on where to document, but this is
getting confusing enough that it should be done.)

best,
-benjamin