Re: [Vala] Private variable/function/class
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 as public names, this is wrong IMHO. Anyway, Jonas' hack solved the problem for me (thx again). -- Bernhard ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Private variable/function/class
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 ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Private variable/function/class
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 variable named
> "testVar" it acts like a one single global variable/function, but it
> should be private!
>
> I think valac should compile private variables/functions using the C
> "static" modifier?
>
>
> Example .vala file:
>
> private int testVar;
> private void TestFunc(string str) {
>print("TestFunc"+str);
> }
> private class TestClass : GLib.Object {
>private int data;
>public TestClass() {
> this.data = 5;
>}
>public void Method1() {
> print("Method1");
>}
> }
>
> Excerpt from .so symbol Table:
>
> 0d3c T TestFunc
> 309c B testVar
> 0e38 T testclass_Method1
> 0dcf T testclass_construct
> 0f60 T testclass_get_type
> 0e13 T testclass_new
>
>
>
>
> --
> Ulink
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
Hi Ulink,
I discovered this too when I wrote my library in Vala.
What I did to remedy this was compiling in two steps:
First, compile without linking (valac -c) while also using
valac's --symbols switch to output all public C symbols to a .sym file,
second, use a bash script to generate a linker script from the .sym file
which declares all those symbols global and the rest local,
and third, manually link the object files using the previously generated
linker script to only export the wanted symbols.
You can check out the rather hacky code at the github
repo,
specifically
"gen_linker_script.sh" and "Makefile".
This is in no way ideal, but I just wanted to tell you that it's possible.
Jonas
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Private variable/function/class
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 .so with e.g. the same PRIVATE variable named > "testVar" it acts like a one single global variable/function, but it > should be private! 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. Also, -fno-common may solve this--I haven't played with it enough to be sure. I'm also not sure how compilers other than GCC behave here. > I think valac should compile private variables/functions using the C > "static" modifier? static restricts the symbol to a single C compilation unit. Private non-instance members are accessible from anywhere within the Vala compilation unit, and a single Vala compilation unit can (and more often than not does) result in multiple C compilation units. Private instance members (such as methods in classes without the "static" Vala keyword) which are only accessible from within an instance are, last time I checked, marked as static in the generated C. So are generated symbols such as delegate and free function wrappers. In other words, AFAIK everything which *can* be marked as static without breaking compilation of the generated C already is. It may be possible to hack something together using attributes/pragmas, and the C preprocessor (for example, see http://gcc.gnu.org/wiki/Visibility), but it would have to rely on non-standard compiler characteristics and wouldn't work everywhere. -Evan ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Private variable/function/class
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 like a one single global variable/function, but it
should be private!
I think valac should compile private variables/functions using the C
"static" modifier?
Example .vala file:
private int testVar;
private void TestFunc(string str) {
print("TestFunc"+str);
}
private class TestClass : GLib.Object {
private int data;
public TestClass() {
this.data = 5;
}
public void Method1() {
print("Method1");
}
}
Excerpt from .so symbol Table:
0d3c T TestFunc
309c B testVar
0e38 T testclass_Method1
0dcf T testclass_construct
0f60 T testclass_get_type
0e13 T testclass_new
--
Ulink
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
