[EXPIRED] Windows binary

[sergeevabc]

Dear Gary,
Could you be so kind to generate .exe for the rest of us who are merely users w/o compiler?

[refi64]

YES PLEASE, especially on Windows. I wanted to burn something after spending ~30 minutes trying to build ucg under Cygwin. It baffles me that people complain about C/C++ development on Linux...

[gvansickle]

Hey @sergeevabc , good to hear from you. I'd love to, and in fact it's been on the todo list here for a long time: see #23 , "Get building on MinGW-64" (that's effectively native Windows). The problem so far has been that I'm depending on two libraries which don't exist for native Windows: the fts file traversal library and the argp library. I'm rewriting the code to eliminate the dependency on the former, and have longer-term plans to eliminate the latter.
There is a Windows option available if you happen to be running Cygwin; ucg works well on Cygwin. However, I don't have a binary available at the moment.
What sort of setup are you looking for exactly? A no-dependencies, run-under-cmd.exe sort of thing? That's what you'll get once I get back to #23. Or a Cygwin package? Or something else?

[sergeevabc]

@gvansickle, thank you for a quick reply. I believe it’s called static build, i.e. no-dependencies.

[gvansickle]

Hey @kirbyfan64 , good to hear from you again! What were the issues trying to build under Cygwin? Just the normal Cygwin issues that it kinda/sorta/isn't native Windows, or was it something with the ucg configuration etc? Cygwin is definitely one of the primary supported platforms, and I believe I've made some improvements recently to the autoconf etc. infrastructure which should streamline things further. However, if you're installing Cygwin just to get ucg, I do apologize; again, that's why the too-long-neglected #23 exists. Are you too looking for a non-Cygwin/run-it-under-cmd.exe binary?

[sergeevabc]

@gvansickle, by the way, evaluate ripgrep: it mentions ugc in README.md and offers Windows binary.

[refi64]

Just the normal Cygwin issues that it kinda/sorta/isn't native Windows, or was it something with the ucg configuration etc?

Normal Cygwin crud.

Maybe you'd find this interesting; it's a project to let people distribute Cygwin-compiled binaries.

[gvansickle]

Hey @sergeevabc , @kirbyfan64 ,

I looked into this again, and argp is at this point the main stumbling block; there appears to be no real option for MinGW. There are some which purport to be, but they're old and I can't get them to build. I wrote up #94 a while ago questioning whether to roll my own arg parsing, and this is one more good reason to do so.

[refi64]

@gvansickle Maybe you'd find TCLAP interesting?

[gvansickle]

Thanks @kirbyfan64 , that's one I hadn't seen before. It does look interesting..... This one looks even better: http://optionparser.sourceforge.net/index.html

[gvansickle]

Hmmm, yeah, it's coming back to me now:

checking for openat... no
checking for fstatat... no
checking for aligned_alloc... no
checking for posix_memalign... no
configure: error: cannot find an aligned memory allocator.

This is gonna be like the OSX thing all over again ;-).

[refi64]

Wait, are you trying this natively, or inside Cygwin? Because, if it's nativel, you're going to have to rewrite everything that uses fcntl.h...

[gvansickle]

I want to have a native Win64 executable, if for no other reason than to be all things to all people... well, some things to the most people practically possible at any rate. Like I said, it already builds and runs fine under Cygwin; but even I (a Cygwin user/sometimes-contributor since the Cygnus days) think it's a bridge too far to ask people to install Cygwin just to get the awesomeness of ucg ;-). Yes, some chunks will have to be rewritten, but I have other reasons to do a lot of that (dir tree traversal and arg parsing are two which have nothing really to do with portability to Windows).

I did take a quick look at Cygnal, and will have to give that some serious thought. It of course can't be as simple as putting a DLL in the same directory: I'm currently linking to five "cygsomething.dll"s according to ldd, and then it needs an installer, and then what's the best way to put it on the User's (or System's?) PATH, etc etc etc. Then there are licensing concerns: the Cygwin folks are on the ball when it comes to enforcing the terms of the GPL, and I don't have a huge desire to ship tons of source code with every binary. And to @sergeevabc 's original point, there's no such thing as a statically-linked Cygwin binary.

What I do need to do is package up the binary for Cygwin, but I should also do that for Debian, and OSX, and the dozens of RPM variants which refuse to agree on the name they ship libpcre2 under, etc etc etc. If there were only more weeks in the day.....

@kirbyfan64 (and I think I've asked you this before), how are you using ucg? Via Cygwin? Or "in spite of Cygwin", i.e., if you had a statically-linked Windows EXE you'd use that instead? Or something else entirely?

[sergeevabc]

Other multi-platform greps are distributed as standalone .exe perfectly fine: sift, pt, ripgrep.

As for Cygwin, I see this Iconv depends on it and that Iconv, standalone and static, does not.

[sergeevabc]

Six months passed. Err… Hello?

[gvansickle]

Six months?!? Seems like only half a year ago. If I only had more of those round tuits @sergeevabc ! The good news is that the troublesome dependencies are now gone on the master branch. The bad news is I'm doing most of my development on Fedora these days. Thanks for the ping, I definitely haven't forgotten about this.

[ghost]

gvansickle writes:

I did take a quick look at Cygnal, and will have to give that some serious thought. It of course can't be as simple as putting a DLL in the same directory: I'm currently linking to five "cygsomething.dll"s according to ldd, and then it needs an installer, and then what's the best way to put it on the User's (or System's?) PATH, etc etc etc. Then there are licensing concerns: the Cygwin folks are on the ball when it comes to enforcing the terms of the GPL, and I don't have a huge desire to ship tons of source code with every binary. And to @sergeevabc 's original point, there's no such thing as a statically-linked Cygwin binary.

Cygnal provides a replacement for the main cygwin1.dll. So far I have not identified issues which require the other DLL's to be patched.

If you depend on additional DLL's, you can just pull them from the stock Cygwin installation. It's probably a good idea to stay close to the same Cygwin that Cygnal is based from. I just rebased Cygnal to Cygwin 2.9.0 a week ago.

I started the Cygnal project precisely because Cygwin switched to the LGPL license. It is permissible to link even proprietary executables with the Cygwin components. I had the idea for Cygnal prior to that, but the licensing was in the way. In my case, I wanted a decent POSIX library for the Windows port of a BSD-licensed program, without that port of that program becoming GPL-ed as a whole.

I use NSIS for the Windows installer of the TXR language. The script is here:

http://www.kylheku.com/cgit/txr/tree/inst.nsi

As you can see, this is pulling in three DLL's:

File win\cygwin1.dll
File c:\cygwin\bin\cyggcc_s-1.dll
File c:\cygwin\bin\cygffi-6.dll

It's pulling some DLL's right out of the Cygwin installation: the GCC run-time support and Libffi. The win/cygwin1.dll is a local path to the Cygnal version of that DLL (not checked into Git). For the 64 bit version, I have a locally patched version of this installer script which refers to the 64 bit Cygwin installation for the right DLL's.

In the Makefile you can also see an example of how resources are compiled and added to the txr.exe executable so that it has a version and icons. A .res file in the win/ directory is compiled with winres, et cetera. Also, a txr-win.exe is built which launches without a console window; you can see how that is done with the -mwindows option to the Cygwin GCC toolchain; fairly trivial.

Adding the txr.exe directory to the PATH is handled in the installer via some horrid looking functions in win/env.nsh include file; got that from the NSIS website. Removing the PATH entry when it uninstalling is also taken care of.

You can just grab this script and use it as a template for your needs (if NSIS is acceptable).

[sergeevabc]

@kkylheku, being a mere user and not a developer, It is difficult for me to follow your thought to the end.
If there is something I should download, execute and report back, let me know, please.

[sergeevabc]

Err… Hello?