January 18, 2013
On Friday, 18 January 2013 at 18:23:57 UTC, nazriel wrote:
> On Friday, 18 January 2013 at 18:18:07 UTC, Andrej Mitrovic wrote:
>> On 1/18/13, nazriel <spam@dzfl.pl> wrote:
>>> extern(C) void _D3lib3fooFZv();
>>>
>>> void main() {
>>> 	_D3lib3fooFZv();
>>> }
>>
>> That's a *terrible* idea, you are calling a D function using the C
>> convention, you're going to have all sorts of problems. extern(D) is
>> not just used for mangling, it's also used for designating how
>> parameters are passed to and results are returned from a function (via
>> stack/registers). E.g.:
>>
>
> Oh really?
> Thanks, I didn't know.

As a disclaimer, I did know about this.
I wasn't serious by posting this example. So don't take this serious.

I just used objdump to get mangled name. ^^
January 18, 2013
Al 18/01/13 18:47, En/na nazriel ha escrit:
> On Friday, 18 January 2013 at 17:02:51 UTC, Jordi Sayol wrote:
>> Is there a way to use a function from a static D library without importing their D sources nor their DI interface?
> 
> lib.d:
> 
> extern(C) void printf(const char*, ...);
> 
> void foo() {
>     printf("%s".ptr, "hi".ptr);
> }
> 
> test.d:
> 
> extern(C) void _D3lib3fooFZv();
> 
> void main() {
>     _D3lib3fooFZv();
> }
> 
> Hehe.
> 
> Now, to be honest that is a good question. How to handle name mangling? Maybe pragma(mangleOf, "") by Alex Petterson could help.
> 

Thanks!

Why it works with "extern(C)", but not works with "extern(D)"?

-- 
Jordi Sayol
January 18, 2013
On Friday, 18 January 2013 at 18:34:24 UTC, Jordi Sayol wrote:
> Al 18/01/13 18:47, En/na nazriel ha escrit:
>> On Friday, 18 January 2013 at 17:02:51 UTC, Jordi Sayol wrote:
>>> Is there a way to use a function from a static D library without importing their D sources nor their DI interface?
>> 
>> lib.d:
>> 
>> extern(C) void printf(const char*, ...);
>> 
>> void foo() {
>>     printf("%s".ptr, "hi".ptr);   }
>> 
>> test.d:
>> 
>> extern(C) void _D3lib3fooFZv();
>> 
>> void main() {
>>     _D3lib3fooFZv();
>> }
>> 
>> Hehe.
>> 
>> Now, to be honest that is a good question. How to handle name mangling?
>> Maybe pragma(mangleOf, "") by Alex Petterson could help.
>> 
>
> Thanks!
>
> Why it works with "extern(C)", but not works with "extern(D)"?

I shouldn't paste this code in first place.

As far as I know and other folks mentioned there is no "clean" way to call function from D library without using .DI files or marking function in library as extern (C).

You can always look up symbol table like I did for this example.

Summary:
If you write library - you can mark function as extern (C) to call it later from other app without .DI fil.
You need to create .DI file if you use someone else library.
January 18, 2013
On 1/18/13, nazriel <spam@dzfl.pl> wrote:
> So don't take this serious.

This is D.learn, so people expect to get valid information here and they don't know if you're showing an invalid example or not unless you tell them.
January 18, 2013
On Friday, 18 January 2013 at 18:44:29 UTC, Andrej Mitrovic wrote:
> On 1/18/13, nazriel <spam@dzfl.pl> wrote:
>> So don't take this serious.
>
> This is D.learn, so people expect to get valid information here and
> they don't know if you're showing an invalid example or not unless you
> tell them.

It's valid example as long as you objump object file.

Show me a working solution to question from first post.

"How to use existing static D library *WITHOUT* using .DI files".
You can't edit library itself, so adding extern(C) to functions won't work.
You can't create .DI file - which is the main question from first post.
January 18, 2013
On Friday, 18 January 2013 at 17:47:42 UTC, nazriel wrote:
> lib.d:
>
> extern(C) void printf(const char*, ...);
>
> void foo() {
> 	printf("%s".ptr, "hi".ptr);	
> }
>
> test.d:
>
> extern(C) void _D3lib3fooFZv();
>
> void main() {
> 	_D3lib3fooFZv();
> }

On Friday, 18 January 2013 at 18:18:07 UTC, Andrej Mitrovic wrote:
> That's a *terrible* idea, you are calling a D function using the C
> convention, you're going to have all sorts of problems. extern(D) is
> not just used for mangling, it's also used for designating how
> parameters are passed to and results are returned from a function (via
> stack/registers).

On Friday, 18 January 2013 at 18:50:01 UTC, nazriel wrote:
> It's valid example as long as you objump object file.

It's a bad example. You just got lucky in that the calling conventions match in that particular case.
January 18, 2013
On 1/18/13, nazriel <spam@dzfl.pl> wrote:
> Show me a working solution to question from first post.
>
> "How to use existing static D library *WITHOUT* using .DI files".
> You can't edit library itself, so adding extern(C) to functions
> won't work.
> You can't create .DI file - which is the main question from first
> post.

That formulation makes no sense. If it's not his library the provider will either give the .d files or autogenerated/handwritten .di files. He won't just get a naked static library without supporting files.

And if he controls the library, he will either have to autogenerate .di files, or handwrite them. Even if he uses extern(C) he will still have to provide a .d file with all extern(C) functions and types.
January 18, 2013
On Friday, 18 January 2013 at 20:33:04 UTC, Andrej Mitrovic wrote:
> On 1/18/13, nazriel <spam@dzfl.pl> wrote:
>> Show me a working solution to question from first post.
>>
>> "How to use existing static D library *WITHOUT* using .DI files".
>> You can't edit library itself, so adding extern(C) to functions
>> won't work.
>> You can't create .DI file - which is the main question from first
>> post.
>
> That formulation makes no sense. If it's not his library the provider
> will either give the .d files or autogenerated/handwritten .di files.
> He won't just get a naked static library without supporting files.
>
> And if he controls the library, he will either have to autogenerate
> .di files, or handwrite them. Even if he uses extern(C) he will still
> have to provide a .d file with all extern(C) functions and types.

Still doesn't answers question from first post.

So let me quote it for you:
"Is there a way to use a function from a static D library without importing their D sources nor their DI interface?"

There were 2 types of answers in this topic:
1) Yes, you can if functions in library are marked as extern(C)
2) Yes, you can even if functions are not marked as extern(C) with little hack which is dumping object file.

Whatever you think it is *terrible* idea or not, it seems to be the only one working idea in this, specific scenario.
January 18, 2013
On 1/18/13, nazriel <spam@dzfl.pl> wrote:
> There were 2 types of answers in this topic:
> 1) Yes, you can if functions in library are marked as extern(C)

You still have to provide .d or .di files, you can't expect the user to have to manually write extern declarations.

> 2) Yes, you can even if functions are not marked as extern(C)
> with little hack which is dumping object file.

That little hack is not very reliable. And once Pull 1085 is merged that technique will become completely unreliable. (https://github.com/D-Programming-Language/dmd/pull/1085).

> Whatever you think it is *terrible* idea or not, it seems to be the only one working idea in this, specific scenario.

The terrible idea is using the mangled representation of a D function but calling it as an extern(C) function. This will simply not work properly.

Using extern(C) properly is fine, of course. However even that is problematic because extern(C) does not allow you to overload functions and you'll have 64bit breakage due to http://d.puremagic.com/issues/show_bug.cgi?id=5570.
January 20, 2013
Al 18/01/13 21:32, En/na Andrej Mitrovic ha escrit:
> On 1/18/13, nazriel <spam@dzfl.pl> wrote:
>> Show me a working solution to question from first post.
>>
>> "How to use existing static D library *WITHOUT* using .DI files".
>> You can't edit library itself, so adding extern(C) to functions
>> won't work.
>> You can't create .DI file - which is the main question from first
>> post.
> 
> That formulation makes no sense. If it's not his library the provider will either give the .d files or autogenerated/handwritten .di files. He won't just get a naked static library without supporting files.
> 
> And if he controls the library, he will either have to autogenerate .di files, or handwrite them. Even if he uses extern(C) he will still have to provide a .d file with all extern(C) functions and types.
> 

Thank you for your answer.
What's the sense for extern(D)? and in which case is useful.

-- 
Jordi Sayol