Re: Why can meson find hunt-net but not hunt-proton in dependency resolution?
On Wednesday, 1 April 2020 at 01:56:26 UTC, Heromyth wrote: On Wednesday, 1 April 2020 at 01:21:22 UTC, YD wrote: [...] Sorry for the inconveniences. We are still testing Hunt-AMQP. The problems about dub.json will be fixed soon. Thanks for the reply! BTW is hunt-amqp for AMQP 1.0 only? Because when I try it on an AMQP 0.9 server, it does not seem to connect. Thanks again!
Re: Why can meson find hunt-net but not hunt-proton in dependency resolution?
On Tuesday, 31 March 2020 at 19:59:25 UTC, YD wrote:
On Tuesday, 31 March 2020 at 19:51:31 UTC, YD wrote:
Hi, I am trying to use Meson, and I did the followings to get
dub packages:
dub fetch hunt-net
dub fetch hunt-proton
dub build hunt-net
dub build hunt-proton
when I have this line in my meson.build file:
dependency('hunt-net', method: 'dub')
It works fine:
Run-time dependency hunt-net found: YES 0.4.6
But when I change it to
dependency('hunt-proton', method: 'dub')
It simply says:
Run-time dependency hunt-proton found: NO
... ERROR: Dependency "hunt-proton" not found
And when I looked at meson-log.txt, I couldn't find any clue
on why that happens:
Determining dependency 'hunt-proton' with DUB executable
'.../dlang/dmd-2.091.0/linux/bin64/dub'
Run-time dependency hunt-proton found: NO
So I completely cannot figure out why hunt-net is resolvable
but hunt-proton is not. Can anyone help me understand how
meson resolves these dependencies? Thanks!
I have a feeling that it might be because of the fact that
hunt-proton has a "beta" in its version:
hunt-net 0.4.6:
/home/.../.dub/packages/hunt-net-0.4.6/hunt-net/
hunt-proton 1.0.0-beta.3:
/home/.../.dub/packages/hunt-proton-1.0.0-beta.3/hunt-proton/
However, this does not help me solve the problem. Even if I add
a "version" parameter to the dependency() function, it still
does not resolve hunt-proton.
Any help will be greatly appreciated, thanks.
So I found that the issue is that dub.json file in hunt-proton
has an entry referring to the parent package with a relative file
path in it. When that relative file path is removed, Meson can
find hunt-proton.
However, even after Meson found it, there are two bad behaviors:
(1) Meson refused to automatically add the dependencies of
hunt-proton, and I had to manually add them to meson.build.
(2) Meson did not automatically add the appropriate
d_module_versions setting that is required by hunt (the
HAVE_EPOLL/HAVE_IOCP/... setting), and I had to manually add that
too.
Anyway, after manually tweaking the meson.build file like above,
I got it to work (except that compiling/linking seems quite slow).
Re: Why can meson find hunt-net but not hunt-proton in dependency resolution?
On Tuesday, 31 March 2020 at 19:51:31 UTC, YD wrote:
Hi, I am trying to use Meson, and I did the followings to get
dub packages:
dub fetch hunt-net
dub fetch hunt-proton
dub build hunt-net
dub build hunt-proton
when I have this line in my meson.build file:
dependency('hunt-net', method: 'dub')
It works fine:
Run-time dependency hunt-net found: YES 0.4.6
But when I change it to
dependency('hunt-proton', method: 'dub')
It simply says:
Run-time dependency hunt-proton found: NO
... ERROR: Dependency "hunt-proton" not found
And when I looked at meson-log.txt, I couldn't find any clue on
why that happens:
Determining dependency 'hunt-proton' with DUB executable
'.../dlang/dmd-2.091.0/linux/bin64/dub'
Run-time dependency hunt-proton found: NO
So I completely cannot figure out why hunt-net is resolvable
but hunt-proton is not. Can anyone help me understand how meson
resolves these dependencies? Thanks!
I have a feeling that it might be because of the fact that
hunt-proton has a "beta" in its version:
hunt-net 0.4.6: /home/.../.dub/packages/hunt-net-0.4.6/hunt-net/
hunt-proton 1.0.0-beta.3:
/home/.../.dub/packages/hunt-proton-1.0.0-beta.3/hunt-proton/
However, this does not help me solve the problem. Even if I add a
"version" parameter to the dependency() function, it still does
not resolve hunt-proton.
Any help will be greatly appreciated, thanks.
Why can meson find hunt-net but not hunt-proton in dependency resolution?
Hi, I am trying to use Meson, and I did the followings to get dub
packages:
dub fetch hunt-net
dub fetch hunt-proton
dub build hunt-net
dub build hunt-proton
when I have this line in my meson.build file:
dependency('hunt-net', method: 'dub')
It works fine:
Run-time dependency hunt-net found: YES 0.4.6
But when I change it to
dependency('hunt-proton', method: 'dub')
It simply says:
Run-time dependency hunt-proton found: NO
... ERROR: Dependency "hunt-proton" not found
And when I looked at meson-log.txt, I couldn't find any clue on
why that happens:
Determining dependency 'hunt-proton' with DUB executable
'.../dlang/dmd-2.091.0/linux/bin64/dub'
Run-time dependency hunt-proton found: NO
So I completely cannot figure out why hunt-net is resolvable but
hunt-proton is not. Can anyone help me understand how meson
resolves these dependencies? Thanks!
Re: A question about C++ interop
On Sunday, 29 March 2020 at 17:32:59 UTC, kinke wrote:
On Sunday, 29 March 2020 at 15:20:52 UTC, YD wrote:
So what do I need to declare in the D file for it to match the
library entry? Thanks!
This is similar to
https://issues.dlang.org/show_bug.cgi?id=19260, and can be
worked around the same way by messing manually with the mangled
name, if you can't adapt the C++ side. The actual problem is
that you can't express a mutable reference to a const class
object (as opposed to a struct) in D (`const Y` is a const
reference to a const Y object).
(This problem somehow does not appear on Linux where the
library file is compiled with gcc, though)
The Itanium C++ mangling doesn't differentiate between:
void foo(const Y *); // what you have on the C++ side
void foo(const Y * const); // corresponds to D `void foo(const
Y)`
Thanks! I tried this:
class X {
version(Windows) {
pragma(mangle, X.call.mangleof.replace("QBV","PBV"))
final void call(const(Y)) const;
} else {
final void call(const(Y)) const;
}
}
and it worked. Thanks very much again!
Re: A question about C++ interop
On Sunday, 29 March 2020 at 15:20:52 UTC, YD wrote: On Sunday, 29 March 2020 at 01:50:24 UTC, evilrat wrote: [...] Thanks, dummy placeholder works. But there is a new problem on Windows, let's say there are two classes in C++: [...] Actually I found that if I create a C wrapper like extern "C" void X_call(X const *, Y const *); then it will work. So I have a workaround now. However, out of curiosity, is there a way to do this directly without C wrapper? Thanks.
Re: A question about C++ interop
On Sunday, 29 March 2020 at 01:50:24 UTC, evilrat wrote:
...
Same here, STL bindings is not yet finished. If you don't need
that method specifically, just replace it with a dummy. Or make
your own bindings.
Thanks, dummy placeholder works. But there is a new problem on
Windows, let's say there are two classes in C++:
class Y {
...
};
class X {
public:
void call(Y const * y) const;
};
on Windows, the library file (compiled with Visual C++) contains
an entry like this:
16C 0020 SECT4 notype ()External |
?call@X@@QBEXPBVY@@@Z (public: void __thiscall X::call(class Y
const *)const )
Then I declare it in D like this:
extern(C++) {
class Y {
...
}
class X {
final void call(const(Y) y) const;
}
}
The object file for this D code (compiled with ldc2) will contain
an entry like this:
0A7 UNDEF notype External |
?call@X@@QBEXQBVY@@@Z (public: void __thiscall X::call(class Y
const * const)const )
So there is a subtle difference in the signature, and the linker
refuses to resolve the symbol.
I tried "const Y y", "const(Y*) y", and "ref const(Y) y", but
none of them manages to match the library file entry.
(This problem somehow does not appear on Linux where the library
file is compiled with gcc, though)
So what do I need to declare in the D file for it to match the
library entry? Thanks!
Re: A question about C++ interop
On Saturday, 28 March 2020 at 07:33:38 UTC, Jacob Carlborg wrote:
On 2020-03-27 20:17, YD wrote:
Hi, I have a C++ header file which looks like
class A {
public:
static A *create();
virtual int f() const = 0;
};
And there is a C++ library file which provides the
implementation, so that if I write a C++ program and call
auto *p = A::create();
std::cout << p->f() << '\n';
It will work.
Now I want to interface to this C++ library through D, and I
wrote
module test;
import std.stdio;
extern(C++) {
class A {
static A *create();
abstract int f() const;
}
}
void main() {
auto p = A.create();
writeln(p.f());
}
This program will compile and link, but it core dumps at the
call to f().
If I wrap up the C++ interface into a C interface (using a
void *), and interface to the wrapped-up C library through D,
it will work fine.
So what am I doing wrong here? Thanks!
Classes in D are always passed by reference. Try dropping the
pointer in the `create` method:
static A create();
Hi, now I have a further question: when the C++ class A actually
has a method that looks like
virtual void get_info(std::string ) const = 0;
in order to preserve the virtual function table layout (I found
that if I omit this function completely in the D declaration, and
try to use a virtual member function originally defined in C++
after this function, the result is core dump), even if I don't
use this function, in the D file I have to put in line like this
abstract void get_info(basic_string!(char) s) const;
When I try this on Linux (Ubuntu 18.04), the compiler (both dmd
and ldc2) will complain about "std::__cxx11::basic_string is not
yet supported", but otherwise the code compiles and links
correctly, and can run without problem.
But when I try this on Windows 10, dmd will simply refuse to
compile it, saying "windows c++ runtime not supported", and ldc2
will allow the compilation but fail at the linking stage, saying
something like
"error LNK2019: unresolved external symbol
__D4core6stdcpp9allocator33_Allocate_manually_vector_alignedFNixkZPv referenced in function __D4core6stdcpp9allocator__TQnTaZQs8allocateMFNikZPa"
So does this mean that there is no way I can interface to this
C++ API in Windows? Thanks.
Re: A question about C++ interop
On Saturday, 28 March 2020 at 07:33:38 UTC, Jacob Carlborg wrote: On 2020-03-27 20:17, YD wrote: [...] Classes in D are always passed by reference. Try dropping the pointer in the `create` method: static A create(); Thanks! I got it to work for now.
A question about C++ interop
Hi, I have a C++ header file which looks like
class A {
public:
static A *create();
virtual int f() const = 0;
};
And there is a C++ library file which provides the
implementation, so that if I write a C++ program and call
auto *p = A::create();
std::cout << p->f() << '\n';
It will work.
Now I want to interface to this C++ library through D, and I wrote
module test;
import std.stdio;
extern(C++) {
class A {
static A *create();
abstract int f() const;
}
}
void main() {
auto p = A.create();
writeln(p.f());
}
This program will compile and link, but it core dumps at the call
to f().
If I wrap up the C++ interface into a C interface (using a void
*), and interface to the wrapped-up C library through D, it will
work fine.
So what am I doing wrong here? Thanks!
