multiple windows dlls results in "entry point could not be located" depending on order
I have built 2 windows C dlls (ctst and ctst2) that I am calling
from a Dlang exe (dtstx). dumpbin shows the exports.
dpp was used to generate the d file from #includes.
All this works perfectly on Linux and MacOS.
(Are the generated d files portable? They seem to be. I have also
generated them on Windows just in case.)
dtstx calls ctst_init() and ctst2_init().
```
import c_libs;
int mymain(string[] args) {
string str = "dlang";
return ctst_init(str.toStringz) + ctst2_init(str.toStringz);
}
```
If I call just **one** of the fns ctst_init and ctst2_init, it
works.
However, calling **both** gives either of these errors:
In dub.sdl
```
libs "lib/ctst" "lib/ctst2" platform="windows"
```
causes dtstx to generate
```
---
dtstx.exe - Entry Point Not Found
---
The procedure entry point ctst2_init could not be located in the
dynamic link library \dtstx\bin\dtstx.exe.
---
```
In dub.sdl, reversing the order of the libs:
```
libs "lib/ctst2" "lib/ctst" platform="windows"
```
causes dtstx to generate
```
---
dtstx.exe - Entry Point Not Found
---
The procedure entry point ctst_init could not be located in the
dynamic link library \dtstx\bin\dtstx.exe.
---
```
Re: Exceptions on Windows being "swallowed"
On Wednesday, 27 November 2019 at 05:43:33 UTC, Mike Parker wrote:
On Wednesday, 27 November 2019 at 05:15:10 UTC, cartland wrote:
*snip*
dmd -m32mscoff -debug -g x.d
And see what happens.
No difference between "dmd -m32mscoff -debug -g x.d" and "dmd
-m32mscoff x.d"
C:\tmp\x>dmd -m32mscoff -debug -g x.d
C:\tmp\x>x
hello
C:\tmp\x>dmd x.d
C:\tmp\x>x
hello
finally
catch first
done
--
x.d contents
import std.stdio;
void main() {
writeln("hello");
try {
try {
throw new Exception("first");
} finally{
writeln("finally");
throw new Exception("second");
}
} catch (Exception e) {
writeln("catch ", e.msg);
}
writeln("done");
}
---
Re: Exceptions on Windows being "swallowed"
This works (once I installed Microsoft Visual C++ 2010 x64 Redistributable) : dub --force -v Seems the issue is with "x86_mscoff" -- : Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for x86_64. x ~master: building configuration "application"... C:\D\dmd2\windows\bin\dmd.exe -m64 -c -of.dub\build\application-debug-windows-x86_64-dmd_2089-1DF706DBEDBB125C8784D2CAFEE4D94A\x.obj -debug -g -w -version=Have_x -Isource source\app.d -vcolumns Linking... C:\D\dmd2\windows\bin\dmd.exe -of.dub\build\application-debug-windows-x86_64-dmd_2089-1DF706DBEDBB125C8784D2CAFEE4D94A\x.exe .dub\build\application-debug-windows-x86_64-dmd_2089-1DF706DBEDBB125C8784D2CAFEE4D94A\x.obj -m64 -g Copying target from C:\tmp\x\.dub\build\application-debug-windows-x86_64-dmd_2089-1DF706DBEDBB125C8784D2CAFEE4D94A\x.exe to C:\tmp\x Running .\x.exe finally catch %sfirst done
Re: Exceptions on Windows being "swallowed"
On Wednesday, 27 November 2019 at 04:11:44 UTC, Mike Parker wrote: On Wednesday, 27 November 2019 at 02:48:53 UTC, cartland wrote: Trying out exception handling. When an exception occurs, program seems to just exit. dub -a x86_mscoff I compiled it with dmd and ran it directly from the command line and it worked fine: hmmm! Did you try that? And do you have the MS linker installed or are you using the lld that ships with DMD? No MS installed. Just using DMD. - dub -a x86_mscoff --force -v : Generating using build Configuring dependent x, deps: Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for x86, x86_mscoff. x ~master: building configuration "application"... C:\D\dmd2\windows\bin\dmd.exe -m32mscoff -c -of.dub\build\application-debug-windows-x86.x86_mscoff-dmd_2089-6ACE9C396DEB2C31A239A4E275587962\x.obj -debug -g -w -version=Have_x -Isource source\app.d -vcolumns Linking... C:\D\dmd2\windows\bin\dmd.exe -of.dub\build\application-debug-windows-x86.x86_mscoff-dmd_2089-6ACE9C396DEB2C31A239A4E275587962\x.exe .dub\build\application-debug-windows-x86.x86_mscoff-dmd_2089-6ACE9C396DEB2C31A239A4E275587962\x.obj -m32mscoff -g Copying target from C:\tmp\x\.dub\build\application-debug-windows-x86.x86_mscoff-dmd_2089-6ACE9C396DEB2C31A239A4E275587962\x.exe to C:\tmp\x Running .\x.exe Program exited with code -532414463 Two things regarding your code: Thanks for the advice. It was just a quick cut and paste from the sample code to test.
Exceptions on Windows being "swallowed"
Trying out exception handling. When an exception occurs, program
seems to just exit.
dub -a x86_mscoff
Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for
x86, x86_mscoff.
x ~master: target for configuration "application" is up to date.
To force a rebuild of up-to-date targets, run again with --force.
Running .\x.exe
Program exited with code -532414463
---
//from https://dlang.org/spec/statement.html#try-statement
import std.stdio;
int main(){
try{
try {
throw new Exception("first");
} finally {
writeln("finally");
throw new Exception("second");
}
} catch (Exception e){
writeln("catch %s", e.msg);
}
writeln("done");
return 0;
}
---
(SOLVED) Re: linking to shared lib on Windows
On Wednesday, 13 November 2019 at 00:47:11 UTC, cartland wrote: I now have the following working on Linux and macOS. *snip* What is the approach on Windows these days (many posts on the matter seem out of date)? The shared C dll was built in MSYS2/MINGW32. *snip* FYI Got it working using the sdl below. libmylib.lib/dll is built using the msys2 mingw32 toolchain. I have a cmd file which wraps dub: rdub.cmd -- set DLANG_DUB_LIBS=..\..\_cache\libmylib mkdir bin copy "%DLANG_DUB_LIBS%.dll" bin dub -a x86_mscoff %1 %2 %3 %4 %5 -- dub.sdl name "myapp" targetType "executable" description "A minimal D application." authors "bartland" copyright "Copyright © 2019, bartland" license "public" libs "$DLANG_DUB_LIBS" platform="windows" libs "mylib" platform="posix" lflags "-L../../_cache/" "-rpath" "../../_cache/" platform="posix" targetPath "bin" -
Re: (SOLVED) Re: linking to shared lib on Windows
On Tuesday, 19 November 2019 at 10:10:14 UTC, cartland wrote: On Wednesday, 13 November 2019 at 00:47:11 UTC, cartland wrote: *snip* PS I uninstalled ALL Microsoft build tools and Visual Studios, then reinstalled DMD and LDC.
linking to shared lib on Windows
I now have the following working on Linux and macOS. - name "myapp" targetType "executable" description "A minimal D application." authors "bartland" copyright "Copyright © 2019, bartland" license "public" libs "mylib" lflags "-L../../_cache/" "-rpath" "../../_cache/" --- What is the approach on Windows these days (many posts on the matter seem out of date)? The shared C dll was built in MSYS2/MINGW32. On Windows (PATH=C:\D\dmd2\windows\bin;C:\D\dmc\dm\bin): (Looks like it's invoking the MS linker?) Linking... C:\D\dmd2\windows\bin\dmd.exe -of.dub\build\application-debug-windows-x86_64-dmd_2089-5F4166A8E1793C219FB49EC77A7D7D35\myapp.exe .dub\build\application-debug-windows-x86_64-dmd_2089-5F4166A8E1793C219FB49EC77A7D7D35\myapp.obj mylib.lib -L-L../../_cache/ -L-rpath -L../../_cache/ -m64 -g LINK : warning LNK4044: unrecognized option '/L../../_cache/'; ignored LINK : warning LNK4044: unrecognized option '/rpath'; ignored LINK : fatal error LNK1104: cannot open file '../../_cache/.obj' Error: linker exited with status 1104
(SOLVED) Re: rpath on macOS
On Tuesday, 12 November 2019 at 10:44:07 UTC, kinke wrote: On Tuesday, 12 November 2019 at 10:19:30 UTC, cartland wrote: but on macOS with DMD or LDC this gives ld: unknown option: -rpath=../../_cache/" IIRC, Mac's ld64 linker requires 2 separated args: "-rpath" "../../_cache/" Brilliant. lflags "-L../../_cache/" "-rpath" "../../_cache/" also works on Linux. Thanks
Re: rpath on macOS
On Tuesday, 12 November 2019 at 10:19:30 UTC, cartland wrote: On Linux, this works: *snip* but on macOS with DMD or LDC this gives ld: unknown option: -rpath=../../_cache/" Currently I do this post build to get the binary to work: -- install_name_tool -add_rpath "../../_cache" myapp --
rpath on macOS
On Linux, this works: name "myapp" targetType "executable" description "A minimal D application." authors "bartland" copyright "Copyright © 2019, bartland" license "public" libs "mylib" lflags "-L../../_cache/" "-rpath=../../_cache/" but on macOS with DMD or LDC this gives ld: unknown option: -rpath=../../_cache/"
Re: (SOLVED) requests module generates " Can't parse uri '' "
On Sunday, 10 November 2019 at 01:28:13 UTC, cartland wrote:
On Saturday, 9 November 2019 at 01:02:57 UTC, cartland wrote:
On Saturday, 9 November 2019 at 00:53:13 UTC, cartland wrote:
On Friday, 8 November 2019 at 17:01:07 UTC, ikod wrote:
*snip*
Even this does it.
import requests;
void main() {
}
https://github.com/ikod/dlang-requests/issues/109
Figured it out. See github issue. I had http_proxy env var set
to blank. Worked when I unset it.
PS. As a long time C (and C++, Java/script, C#) dev, I'm loving
D. Very impressive so far.
Re: (SOLVED) requests module generates " Can't parse uri '' "
On Saturday, 9 November 2019 at 01:02:57 UTC, cartland wrote:
On Saturday, 9 November 2019 at 00:53:13 UTC, cartland wrote:
On Friday, 8 November 2019 at 17:01:07 UTC, ikod wrote:
*snip*
Even this does it.
import requests;
void main() {
}
https://github.com/ikod/dlang-requests/issues/109
Figured it out. See github issue. I had http_proxy env var set to
blank. Worked when I unset it.
Re: requests module generates " Can't parse uri '' "
On Saturday, 9 November 2019 at 00:53:13 UTC, cartland wrote:
On Friday, 8 November 2019 at 17:01:07 UTC, ikod wrote:
*snip*
Even this does it.
import requests;
void main() {
}
https://github.com/ikod/dlang-requests/issues/109
Re: requests module generates " Can't parse uri '' "
On Friday, 8 November 2019 at 17:01:07 UTC, ikod wrote:
On Friday, 8 November 2019 at 03:29:41 UTC, cartland wrote:
First time D use :)
After dub init, I used the example from
https://code.dlang.org/packages/requests and ran "dub add
requests"
[...]
If you still stuck with this problem, you can post new issue on
github project page, I'll try to solve it.
https://github.com/ikod/dlang-requests
Same on MacOS. Using dmd, ldc, or gdc. I'll raise an issue on
https://github.com/ikod/dlang-requests.
Even this does it.
import requests;
void main() {
}
Re: requests module generates " Can't parse uri '' "
On Friday, 8 November 2019 at 03:43:52 UTC, Adam D. Ruppe wrote: On Friday, 8 November 2019 at 03:36:22 UTC, cartland wrote: * snip * huh, idk, it works when I try that exact code in a fresh project * snip * are you behind a proxy or something maybe? Thanks for checking. I'm not behind a proxy. The firewall allows browsing to the url. Also tried older versions of requests with the same result. The same (similar) call works using std.net.curl. I'm on Tumbleweed. I'll try it on MacOS. And also try a different network a bit later.
Re: requests module generates " Can't parse uri '' "
On Friday, 8 November 2019 at 03:31:56 UTC, Adam D. Ruppe wrote:
On Friday, 8 November 2019 at 03:29:41 UTC, cartland wrote:
When I run dub, I get
What was your main() code?
The error makes me think you might have just tried like get("")
or something
import std.stdio;
import requests;
void main() {
auto content = getContent("https://httpbin.org/get;,
queryParams("name", "any name", "age", 42));
writeln(content);
}
requests module generates " Can't parse uri '' "
First time D use :) After dub init, I used the example from https://code.dlang.org/packages/requests and ran "dub add requests" When I run dub, I get requests.uri.UriException@/home/cartland/.dub/packages/requests-1.0.9/requests/source/requests/uri.d(35): Can't parse uri '' Full output on initial run: Fetching vibe-core 1.7.0 (getting selected version)... Fetching requests 1.0.9 (getting selected version)... Fetching memutils 0.4.13 (getting selected version)... Fetching taggedalgebraic 0.11.7 (getting selected version)... Fetching vibe-d 0.8.6 (getting selected version)... Fetching botan-math 1.0.3 (getting selected version)... Fetching stdx-allocator 2.77.5 (getting selected version)... Fetching botan 1.12.10 (getting selected version)... Fetching diet-ng 1.6.0 (getting selected version)... Fetching openssl 1.1.6+1.0.1g (getting selected version)... Fetching cachetools 0.3.1 (getting selected version)... Fetching eventcore 0.8.48 (getting selected version)... Fetching mir-linux-kernel 1.0.1 (getting selected version)... Fetching libevent 2.0.2+2.0.16 (getting selected version)... Fetching libasync 0.8.4 (getting selected version)... Performing "debug" build using /home/cartland/dlang/dmd-2.089.0/linux/bin64/dmd for x86_64. cachetools 0.3.1: building configuration "library"... requests 1.0.9: building configuration "std"... x ~master: building configuration "application"... Linking... Running ./x requests.uri.UriException@/home/cartland/.dub/packages/requests-1.0.9/requests/source/requests/uri.d(35): Can't parse uri '' Program exited with code 1
