Hi Evan,
> In practice this really isn't an issue. Beyond the fact that I don't
think non-instance variables are widely used (I certainly don't use
many), they should be within your namespace anyways.
I agree, but the basic problem is that even "private" declared variables
are put into the .so a
Hi Jonas,
> This is in no way ideal, but I just wanted to tell you that it's possible.
Yeah, its a little bit hacky, but it works and so its ok for me ;-)
MANY thanks!
Maybe one of the vala guys will fix it in a later valac release (I
really think this is a bug).
--
Bernhard
_
2013/7/15 Ulink
> Hi,
>
> If I'm declaring a private variable/funtion/class and compile it to a
> "package" (.so), it is not shown up in the .h and .vapi, this is ok.
>
> However, all this symbols ARE exported in the .so symbol table!
>
> If one bind more than one .so with e.g. the same PRIVATE v
On Mon, 2013-07-15 at 15:41 +0200, Ulink wrote:
> Hi,
>
> If I'm declaring a private variable/funtion/class and compile it to a
> "package" (.so), it is not shown up in the .h and .vapi, this is ok.
>
> However, all this symbols ARE exported in the .so symbol table!
>
> If one bind more than one
Hi,
If I'm declaring a private variable/funtion/class and compile it to a
"package" (.so), it is not shown up in the .h and .vapi, this is ok.
However, all this symbols ARE exported in the .so symbol table!
If one bind more than one .so with e.g. the same PRIVATE variable named
"testVar" it acts