Madsy
libguile assumes sizeof(void*) == sizeof(long) which breaks 64-bit builds
libguile assumes sizeof(void*) == sizeof(long) which breaks builds where the assertion does not hold, notably when attempting a 64-bit guile build for Windows. It should be patchable with some effort.
A possible hack would be to replace all usage of long, signed long and unsigned long with int64_t and uint64_t from <stdint.h> and specify libguile to be compiled as C99, but only when attempting 64-bit builds. I don't think it's guaranteed to work however. Guile compiles/generates code and interacts with data structures in nontrivial ways, so a simple search/replace is not necessarily sufficient.
@Madsy If you are still working on this, I have an idea.
if [[ ${HOST} == x86_64-w64-mingw32 ]]; then
sed 's,long,int64_t,g;s,signed long,int64_t,g;s,unsigned long,uint64_t,g' ${INCDIR}/stdint.h > include/stdint.h;
for file in $(find . -name '*.c'); do
sed -i 's,<stdint.h>,"include/stdint.h",g' ${file};
done
for file in $(find . -name '*.h'); do
sed -i 's,<stdint.h>,"include/stdint.h",g' ${file};
done
CFLAGS="-O2 -g -std=c99 " ${CONFIGURE};
NO_CONFIGURE=1;
fi
@JL2210 Thanks a lot for the suggestion. It's a bit more complicated however. Guile depends on the GNU MP bignum library which uses "long" in its public API, which becomes 4 bytes on Windows (even in 64-bit builds) because of the Windows LLP64 model. Afaik the author of GNU MP refuses to fix this, so the only workaround would be your suggestion and maintain our own version of GNU MP with a modified public interface.
Anyway, Guile has gone through major changes the last two-three years. I might have a look at the latest version. Maybe it's simpler to start porting there now rather than keep patching these old 2.x versions.
That would be a good idea. The only issue is that Guile depends on a shared libltdl from libtool, which has been a challenge for me to build.
Do you mind if I transition from building Git commits and releases to tarball releases from ftp.gnu.org?
@JL2210 This is somewhat embarrassing.. I have to apologize; I usually manage but I'm not really great at git nor do I have a lot of experience with contributing to upstream projects. Could you please elaborate on your last question? My old build scripts have solely been a solo project until now.
Sure. Basically, I want to stop using the (unstable) Guile Git repository, and start using the (stable) uploaded packages of the source on ftp.gnu.org.
You do.. whatever you want, I guess? Just to clear up some misunderstandings here, because I have no idea what you're asking for. In my spare time, I just happened to make some cross-compilation build script for Guile because cross compilation for Windows is incredibly hard and not officially supported. I'm in no way affiliated with the GNU Guile project, nor do I contribute code to that project.
If you want to contribute to these build scripts, I'll gladly answer any technical questions that arise and I accept pull requests. v2.0.11 is the last stable version of Guile I got working if I recall correctly.
I just happened to make some cross-compilation build script for Guile because cross compilation for Windows is incredibly hard and not officially supported.
On a side note, this sounds just like what I'm trying to do with my "winbuild"s.
If you want to get your Guile source code files from the guile ftp server, sure why not. Just know that the git tags with the version-naming are exactly the same stable commits that are packaged and put on the FTP server. Again, the exact same packaged versions you find on the FTP server is in git under tag names such as "v2.0.9".