I was going to attach this to another thread about extern linking, but couldn't find it.  Basically, the issue is that any global exported symbols in a C library need to be put into a seperate D file that gets imported, but not linked.  For example, see phobos/std/c/linux.
Could we perhaps introduce a "nolink" attribute, that would work as such

extern (C){
	void someFunc();

	nolink {
		int someGlobal;
	}
}

I think that would fit in with the current attribute syntax, and would stop us needing to do the import but don't like trick.  Is this easy, and is this trick required enough to make it a language feature?

Brad

"brad beveridge" <brad@nowhere.com> wrote in message news:cvo54j$1jka$1@digitaldaemon.com...
>I was going to attach this to another thread about extern linking, but couldn't find it.  Basically, the issue is that any global exported symbols in a C library need to be put into a seperate D file that gets imported, but not linked.  For example, see phobos/std/c/linux.
> Could we perhaps introduce a "nolink" attribute, that would work as such
>
> extern (C){
> void someFunc();
>
> nolink {
> int someGlobal;
> }
> }
>
> I think that would fit in with the current attribute syntax, and would stop us needing to do the import but don't like trick.  Is this easy, and is this trick required enough to make it a language feature?
>
> Brad

My first time bumping into this was on 1/31 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15427

There's a pragma for 'build' that works for the entire module:
version(build) { pragma(nolink); }
In case you don't have an URL for build it is
http://www.dsource.org/projects/build/

It would be nice to have a way to do what you suggest, though.

Ah, you're after link-unit-local variables. Interesting.

Doesn't a private variable suffice?



"brad beveridge" <brad@nowhere.com> wrote in message news:cvo54j$1jka$1@digitaldaemon.com...
>I was going to attach this to another thread about extern linking, but couldn't find it.  Basically, the issue is that any global exported symbols in a C library need to be put into a seperate D file that gets imported, but not linked.  For example, see phobos/std/c/linux.
> Could we perhaps introduce a "nolink" attribute, that would work as such
>
> extern (C){
> void someFunc();
>
> nolink {
> int someGlobal;
> }
> }
>
> I think that would fit in with the current attribute syntax, and would stop us needing to do the import but don't like trick.  Is this easy, and is this trick required enough to make it a language feature?
>
> Brad

Matthew wrote:
> Ah, you're after link-unit-local variables. Interesting.
> 
> Doesn't a private variable suffice?
> 
I'm not sure that I get what you mean.  The nolink attribute would be purely for interfacing to C code.  The C lib defines and exports a symbol.  However, in D all symbol definitions also create storage for that symbol, so you end up with the same variable being exported from the C lib and from D - ending up with a symbol conflict when you link. Currently the way to do it is to put all symbols that need to be used in a seperate D module so that D code can resolve the symbols, but then you don't link that particular D module.
The "nolink" attribute would tell D to resolve the symbol while doing the compile, but not to allocate storage for it or anything else, because the linker will find that symbol elsewhere at link time.
nolink would be analoguous to the "extern" keyword in C.

Brad