How to properly disable updates and purge update cache?

[winzilla]

Yes, that's what I'm trying to do, but since this is failing at the libfilezilla stage, it hasn't gotten to compiling the client yet.

[botg]

The error you showed isn't from libfilezilla, it is from compiling an outdated client.

[winzilla]

Okay, I see now, I was using a 3.64 revision instead of 3.65, sorry about the confusion.

I only encounter this error when trying to compile 3.65, which is why I was trying an older revision:

Code: Select all

checking whether x86_64-w64-mingw32-g++ supports C++17 features with -std=c++17... yes
checking for whether we need -stdlib=libc++... no
checking whether std::map has emplace... yes
checking whether std::chrono::steady_clock is steady... yes
checking for thread_local... yes
checking whether std::atomic can be used without link library... yes
checking for whether we need to use Boost Regex due GCC bug 86164... yes
checking for Boost Regex... configure: error: in `/root/src/fz':
configure: error: Boost Regex 1.76 or higher not found.
See `config.log' for more details

Didn't see it with previous versions so I assumed this was something new in 3.65 and it was easier just to use an older one. Though I'm not sure if this is before or after the other error points, so maybe I'm wrong about that.

Since that's an open bug, I guess no version of gcc will avoid the need for Boost Regex 1.76. The package version is 1.74 so I had tried to compile from source, but ran into issues with the bootstrap script there.

Since I assume that you need to compile this from source for all builds anyways, do you have any build scripts that could be used as reference (e.g. as part of CI) as to how you're doing it? Or do you use a distro that has a package for 1.76+?

[botg]

You only need the boos regex headers, no need to compile it.

[winzilla]

Okay, that's good to know, but I still feel that I must be doing something wrong.

For some reason, the bootstrap script is working now, so I was able to run that and then saw there was an option for the headers, in total:

Code: Select all

cd ~/src
wget https://boostorg.jfrog.io/artifactory/main/release/1.76.0/source/boost_1_76_0.tar.bz2
tar --bzip2 -xf boost_1_76_0.tar.bz2
cd boost_1_76_0
./bootstrap.sh --prefix="$HOME/prefix"
./b2 headers

However, I'm still getting "configure: error: Boost Regex 1.76 or higher not found." I tried also running "./b2" to compile everything just in case as well, same thing.

There isn't a boost directory in $HOME/prefix/include, so I don't think it worked properly; it's not in /usr/include, either.

Code: Select all

root@deb12:~/fastfilezilla# find / -name "regex.hpp"
/root/src/boost_1_76_0/boost/regex.hpp
/root/src/boost_1_76_0/boost/regex/v5/regex.hpp
/root/src/boost_1_76_0/boost/regex/v4/regex.hpp
/root/src/boost_1_76_0/boost/iostreams/filter/regex.hpp
/root/src/boost_1_76_0/boost/spirit/home/classic/utility/regex.hpp
/root/src/boost_1_76_0/boost/algorithm/string/regex.hpp
/root/src/boost_1_76_0/boost/log/support/regex.hpp

Are you saying I can just copy /root/src/boost_1_76_0/boost/regex.hpp manually?

I ran the following:

Code: Select all

mkdir -p $HOME/prefix/include/boost
cp /root/src/boost_1_76_0/boost/regex.hpp $HOME/prefix/include/boost/

However, I'm still getting

Code: Select all

configure: error: Boost Regex 1.76 or higher not found.

- is the above not the right place to put the header?

[botg]

You really shouldn't do these things as root, that's a guaranteed one-way ticket to ruin your operating system installation.

Basically take the tarball and move the include directories to the prefix, that's all there is about it.

If that ain't working, check config.log for details.

[winzilla]

This is a VM I created just for this purpose, so no reason not to run as root, I'm nuking this as soon as I'm done.

config.log says the same thing, I'm truly baffled here:

Code: Select all

configure:19184: checking for Boost Regex
configure:19205: x86_64-w64-mingw32-g++ -std=c++17 -c -std=c++17 -Wall -g  conftest.cpp >&5
conftest.cpp:26:18: fatal error: boost/regex.hpp: No such file or directory
   26 |         #include <boost/regex.hpp>
      |                  ^~~~~~~~~~~~~~~~~
compilation terminated.
configure:19205: $? = 1

Despite the header file definitely existing, in multiple places, both the prefix include location as well as the regular system include directory:

Code: Select all

root@deb12:~/fastfilezilla# ls -la /usr/include/boost/regex.hpp
-rw-r--r-- 1 root root 897 Sep  2 07:12 /usr/include/boost/regex.hpp
root@deb12:~/fastfilezilla# ls -la /root/prefix/include/boost/re
ref.hpp        regex/         regex_fwd.hpp  regex.h        regex.hpp
root@deb12:~/fastfilezilla# ls -la /root/prefix/include/boost/regex.hpp
-rw-r--r-- 1 root root 897 Sep  1 21:28 /root/prefix/include/boost/regex.hpp

root@deb12:~/fastfilezilla# ls -la /root/src/fz/config.log
-rw-r--r-- 1 root root 47623 Sep  2 07:13 /root/src/fz/config.log

[winzilla]

Managed to make some progress on this after figuring out that mingw is using different include directories (and what they are). The system include directory was listed, strangely, but didn't work. Using the first one in the list did, copying the entire folder in.

I'm now able to get towards the end, just noticed this bit now fails:

$TARGET_HOST-strip data/dlls/*.dll

ls /root/src/fz/data/dll
dllcopy.sh dll_gui_install.nsh dll_gui_uninstall.nsh dlls_gui/

There doesn't seem to be a dlls directory anymore, but there is a dlls_gui directory, with a bunch of DLLs. I don't remember what happened last time. Was this directory renamed? The documentation here doesn't reflect any change: https://wiki.filezilla-project.org/Cros ... _GNU/Linux

Probably not super important whether debug symbols are stripped or not, just trying to reconcile what's different here.

[winzilla]

I did strip the DLLs in $TARGET_HOST-strip data/dlls_gui/*.dll, though I can't see how that would've done any harm.

It produces a working installer, but when I actually try launching the program, I now get:

The procedure entry point GetSystemTimePreciseAsFileTime could not be located in the dynamic link library KERNEL32.dll.

Looks like after all this fuss, apparently Windows 7 is no longer a supported OS, so 3.65 won't do at all.

What was the last version compatible with Windows 7? I can't find this documented on the wiki.

UPDATE: Actually, seems the dlls_gui may be implicated after all:

root@deb12:~/src/fz# grep -R "GetSystemTimePreciseAsFileTime"
grep: data/dlls_gui/libstdc++-6.dll: binary file matches
grep: data/dlls_gui/libgnutls-30.dll: binary file matches

UPDATE 2: Installing the regular release of 3.65.0 works fine for me, so somehow the cross-compile seems to have introduced the incompatibility. Which is odd, since the 3.62.2 cross compile didn't have this issue. The only thing I've changed is adding the no update flag to configure, plus perhaps using slightly newer versions of certain dependencies, but the incompatibility seems to be in FileZilla itself, not any of those. Just not sure under what circumstances it would manifest.

[botg]

We neither support outdated versions of FileZilla nor outdated operation systems. Please simply update to a more recent operating system (it does not have to be Windows *wink*)

[winzilla]

I'm not asking for user support, or your opinion about older versions of Windows. I'll do no such thing, least of all because the author of FileZilla thinks I should.

I've been wondering if perhaps something here is cross compiling with a Windows >= 8 assumption but haven't been able to narrow that done yet. I explicitly passed Windows 7 to GnuTLS (which seemed to contain references to this function), but still no bueno after recompiling everything.

FileZilla 3.65.0, general release, by the way, seems to work fine on Windows 7, so technically Windows 7 is still supported. The cross-compiling is screwing something up though. It happened with 3.62.2, so I don't think it's the version number (which was what I did last time), but something about the environment or something...

[boco]

It works with Windows 7, fully updated. AFAIK there are problems with non-ESU Windows 7.

[winzilla]

> It works with Windows 7, fully updated.

What works, the general release or cross compiling?
So far on this latest run, no cross-compiles work and all the "standard" prebuilt binaries do.
I suppose it would work if I compiled on Windows 7 directly, rather than cross compiling but.... yuck, I'd prefer not to do that.

Any tips aside from passing --with-default-win32-winnt=0x0601 to every possible configure?

> AFAIK there are problems with non-ESU Windows 7.

I believe I have some of the ESU updates, but probably not all of them. Somehow our slipstreaming procedure broke something with Windows Updates, so lately updates just fail to apply. Shrug.

[boco]

What works, the general release or cross compiling?

Releases. I have no knowledge of compiling, sorry.

[botg]

Try manually setting the various Windows-specific preprocessor defines via CPPFLAGS and recompile it all.