Open 4LT opened 4 months ago
I have tested building this library on Debian, FreeBSD and Windows (msvc/gnu), but not cross compiling. Glad to know it works with cross compiling too.
This project depends on clib to provide C API bindings to tcl/tk. I guess clib's build.rs can set PKG_CONFIG_ALLOW_CROSS=1 or add extra args for bindgen under cross compiling environments.
The tcl's Cargo.toml tries the best to guess the name of tcl library file.
[package.metadata.inwelling.clib.spec.tcl86.libs]
tcl = ["libtcl86.so", "libtcl8.6.so", "libtcl.so", "libtcl86.a", "libtcl.a", "libtcl86.dll.a", "libtcl.dll.a", "tcl86t.dll", "tcl86t.lib"]
If your dll's name is "tcl86.dll", I guess putting it in the array may help to eliminate the necessary of symlink.
Currently the clib crate assumes that native libraries have already been compiled and installed at well known paths/ containing predictable patterns. It does not support source code downloading and compiling yet. Are you requiring such a feature in clib? Seems valuable.
It does not support source code downloading and compiling yet. Are you requiring such a feature in clib?
I don't require it, but it would be nice to have. For Windows platforms I'm distributing libraries for Tcl/Tk with my application as a matter of simplifying installation. I have a script for downloading and building Tcl and Tk, so I've got all my needs covered, but it was a chore to set up.
I have a build script here to demonstrate the difficulty:
https://github.com/4LT/pectin/blob/master/cross_windows.sh
As an example of the nuances I need to account for, make install
actually MUST be run for Tk because pkgIndex.tcl
is generated from the Makefile
Anyways, this is just something I wanted to bring to your attention. As I said, it's a "nice to have"; I would appreciate the process being simplified, but I have no expectations.
I'm having trouble compiling on windows at all - I have everything compiling, right up to the link part (where it spits some nonsense about tk.dll.lib not existing).
I know the package says that it doesn't work well with pkg-config, so if there are windows build instructions, I'm no stranger to difficult builds. :)
It doesn't work on linux either (manjaro install).
It looks like a nice library but I'm going to say you need to offer more instructions on how to get this running, if neither windows nor linux will work out of the box...
I'm having trouble compiling on windows at all - I have everything compiling, right up to the link part (where it spits some nonsense about tk.dll.lib not existing).
I know the package says that it doesn't work well with pkg-config, so if there are windows build instructions, I'm no stranger to difficult builds. :)
I’m not sure if you had read this.
And, this is an issue about cross compiling, not installing failures. I think you’d better starting a delicated issue for your own.
I think you’d better starting a delicated issue for your own.
Perhaps.
I’m not sure if you had read this.
So I tried, actually, three different tcl/tk installations (ActiveState, which was an absolute pain to get, normal tcl/tk, and I even compiled my own tcl/tk with visual studio). I'm not sure what counts as "installed" and your documentation is sparse on that definition. Per my other comment, you may want to consider removing the "magic" clib and expose more of the binding process, its clearly not working well, and its fairly obtuse to debug.
FWIW, I got the other tcl/tk binding packages working fine (the one's that require you to bind to a separate install), I was hoping for a more embedded approach with this library. But clearly its your library not tk not tcl, that are the issue, as it can't compile itself on either linux or windows or linux to windows...
I don't know if this would be in-scope for the project or not but...
I found it difficult to cross-compile from Linux to Windows. While possible, I think it could be more ergonomic.
The command I eventually landed on looks like this:
Where
scratch/tcl-${tcl_tag}/win/build
is the relative path where I havetcl86.dll
built. (Additionally, I have to create a symlink fromtcl8.6.dll
->tcl86.dll
for the tcl crate to find the lib, based on the defaultmake
behavior from the Tcl source.)Ideally I'd like to be able to configure the path to the Tcl lib elsewhere and be able to just run
cargo build --target=x86_64-pc-windows-gnu --release
to build an executable.In particular, the
BINDGEN_EXTRA_CLANG_ARGS='-D__int64="long long" -Dssize_t=int64_t'
bit is a bit silly, apparently some sort of clang behavior that deviates from GCC. (So far as I can tell,__int64
is only recognized by MSVC, although clang already appears to define__GNUC__
by default, so I have no idea why__int64
is reached).I'd also like to say that you're bindings are working terrifically! I've had no problems with the code I've written to consume the
tcl
crate, and I've had reports that it's working under Windows (through a cross-compile build I've handed out) as well.