From: Vic L. <ll...@16...> - 2010-07-21 12:16:16
|
On Tue, 2010-07-20 at 21:31 +0200, Mads Kiilerich wrote: > Vic Lee wrote, On 07/20/2010 05:35 PM: > > On Tue, 2010-07-20 at 17:13 +0200, Mads Kiilerich wrote: > >> But ... > >> > >> Our get_wstr should really be statically linked inside the channel > >> plugin and not link dynamically with anything else. I hope that getting > >> proper encapsulation of internals is on the agenda before 1.0. > > It is statically linked in every plugin actually, and it's not public > > API. But even its statically linked, as long as the function is not > > declare as "static", it will have function name conflict problem. > > $ nm channels/rdpdr/disk/.libs/disk.so|grep get_wstr > 00004330 T get_wstr > > What do you mean when you say "It is statically linked in every plugin"? > > I agree that it isn't "in the public API" because "it isn't documented > anywhere that it is in the public API". But technically it _is_ in the > API, AFAICS. You are right, technically it has no big difference with any other API function defined in include/freerdp/*.h. It's just conceptually not public because it's not defined in public development header so ui developers won't use it. > > AFAIK it is possible with proper encapsulation / export control / > visibility to allow symbols to be shared between compilation units of a > library while they externally is as invisible as if they had been > declared static. I am no expert in this area, but I have read > http://people.redhat.com/drepper/dsohowto.pdf, especially section 2.2. And yes ideally we should declare visibility for every non-static function. This requires quite a lot of work though. > Hmm. Yeah, I guess you are right in most cases. I hadn't considered > that simple conversion between utf-8 and utf-16-ish was trivial. I guess > that must linux/mac users would be happy with a configuration option > assuming utf-8 encoding locally. That trivial recoding you mention > should replace our current naïve no-iconv case, both in channels/common > and in rdp.c. But we don't want it implemented twice! ;-) Sure. I think it's good to move libcommon to root level not just channel/common. |