Why is the filezilla.exe sometimes in src/interface folder?
Moderator: Project members
Why is the filezilla.exe sometimes in src/interface folder?
I don't know why sometimes my building filezilla.exe is in src/interface but not src/interface/.libs. And the directory src/interface/.libs is empty. So both striping and Compiling the installer script failed
But I copy and strip manually filezilla.exe. It can start as normal.
What's wrong?
But I copy and strip manually filezilla.exe. It can start as normal.
What's wrong?
Re: Why is the filezilla.exe sometimes in src/interface folder?
Wish I knew. The .libs directory is something Libtool creates. I have no idea why on some systems it uses a .libs subdirectory and on other systems it doesn't. It should use the .libs directory.
What are you configure arguments? What's your libtool version?
What are you configure arguments? What's your libtool version?
Re: Why is the filezilla.exe sometimes in src/interface folder?
My build sript is here https://github.com/rexdf/build_filezill ... r/build.sh .
Now it depends only on LIBWINPTHREAD-1.DLL and ZLIB1.DLL.
I have remove dependencies on libpng16-16.dll libtasn1-6.dll etc. And with your help remove libstdc++-6.dll.
I find out:
gnutls libwinpthread-1.dll zlib1.dll ( use depends.exe check \build\bin\gnutls-cli.exe ,gnutls-serv.exe, gnutls-cli-debug.exe)
wx3 filezilla libwinpthread-1.dll ( use depends.exe check filezilla.exe)
If I build gnutls with --disable-nls --disable-libdane, everything seems to work. And gnutls will not depend on LIBINTL-8.DLL which is part of mingw-w64-i686-gettext. mingw-w64-i686-gettext has no pc files. So pkg-config cannot find flags. I don't know how to static link, so just disable --disable-nls. I am not sure whether it affects the unicode support in networking.
TL;DR
1)how to make libwinpthread-1.dll zlib1.dll static link
2)Can I disable nls in gnutls with --disable-nls?
3) filezilla.exe sometimes in src/interface folder happens when I change the build.sh script. I really do know how it occurs. I built more than ten times. And now it happens every time. Maybe beacuse I upgrade the msys2 or maybe I use make -j8.
Code: Select all
$ libtool --version
libtool (GNU libtool) 2.4.6
Written by Gordon Matzigkeit, 1996
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I have remove dependencies on libpng16-16.dll libtasn1-6.dll etc. And with your help remove libstdc++-6.dll.
Code: Select all
$ pacman -Qo /mingw32/bin/libwinpthread-1.dll
/mingw32/bin/libwinpthread-1.dll belongs to mingw-w64-i686-libwinpthread-git 5.0.0.4497.4254261-1
$ pacman -Ql mingw-w64-i686-libwinpthread-git
mingw-w64-i686-libwinpthread-git /mingw32/
mingw-w64-i686-libwinpthread-git /mingw32/bin/
mingw-w64-i686-libwinpthread-git /mingw32/bin/libwinpthread-1.dll
mingw-w64-i686-libwinpthread-git /mingw32/share/
mingw-w64-i686-libwinpthread-git /mingw32/share/licenses/
mingw-w64-i686-libwinpthread-git /mingw32/share/licenses/libwinpthread/
mingw-w64-i686-libwinpthread-git /mingw32/share/licenses/libwinpthread/COPYING
mingw-w64-i686-libwinpthread-git /mingw32/share/licenses/libwinpthread/mingw-w64-libraries/
mingw-w64-i686-libwinpthread-git /mingw32/share/licenses/libwinpthread/mingw-w64-libraries/winpthreads/
mingw-w64-i686-libwinpthread-git /mingw32/share/licenses/libwinpthread/mingw-w64-libraries/winpthreads/COPYING
$ pacman -Qo /mingw32/bin/zlib1.dll
/mingw32/bin/zlib1.dll belongs to mingw-w64-i686-zlib 1.2.8-6
$ pacman -Ql mingw-w64-i686-zlib
mingw-w64-i686-zlib /mingw32/
mingw-w64-i686-zlib /mingw32/bin/
mingw-w64-i686-zlib /mingw32/bin/libminizip-1.dll
mingw-w64-i686-zlib /mingw32/bin/miniunzip.exe
mingw-w64-i686-zlib /mingw32/bin/minizip.exe
mingw-w64-i686-zlib /mingw32/bin/zlib1.dll
mingw-w64-i686-zlib /mingw32/include/
mingw-w64-i686-zlib /mingw32/include/minizip/
mingw-w64-i686-zlib /mingw32/include/minizip/crypt.h
mingw-w64-i686-zlib /mingw32/include/minizip/ioapi.h
mingw-w64-i686-zlib /mingw32/include/minizip/iowin32.h
mingw-w64-i686-zlib /mingw32/include/minizip/unzip.h
mingw-w64-i686-zlib /mingw32/include/minizip/zip.h
mingw-w64-i686-zlib /mingw32/include/zconf.h
mingw-w64-i686-zlib /mingw32/include/zlib.h
mingw-w64-i686-zlib /mingw32/lib/
mingw-w64-i686-zlib /mingw32/lib/libminizip.a
mingw-w64-i686-zlib /mingw32/lib/libminizip.dll.a
mingw-w64-i686-zlib /mingw32/lib/libz.a
mingw-w64-i686-zlib /mingw32/lib/libz.dll.a
mingw-w64-i686-zlib /mingw32/lib/pkgconfig/
mingw-w64-i686-zlib /mingw32/lib/pkgconfig/minizip.pc
mingw-w64-i686-zlib /mingw32/lib/pkgconfig/zlib.pc
mingw-w64-i686-zlib /mingw32/share/
mingw-w64-i686-zlib /mingw32/share/licenses/
mingw-w64-i686-zlib /mingw32/share/licenses/zlib/
mingw-w64-i686-zlib /mingw32/share/licenses/zlib/LICENSE
mingw-w64-i686-zlib /mingw32/share/man/
mingw-w64-i686-zlib /mingw32/share/man/man3/
mingw-w64-i686-zlib /mingw32/share/man/man3/zlib.3
gnutls libwinpthread-1.dll zlib1.dll ( use depends.exe check \build\bin\gnutls-cli.exe ,gnutls-serv.exe, gnutls-cli-debug.exe)
wx3 filezilla libwinpthread-1.dll ( use depends.exe check filezilla.exe)
If I build gnutls with --disable-nls --disable-libdane, everything seems to work. And gnutls will not depend on LIBINTL-8.DLL which is part of mingw-w64-i686-gettext. mingw-w64-i686-gettext has no pc files. So pkg-config cannot find flags. I don't know how to static link, so just disable --disable-nls. I am not sure whether it affects the unicode support in networking.
TL;DR
1)how to make libwinpthread-1.dll zlib1.dll static link
2)Can I disable nls in gnutls with --disable-nls?
3) filezilla.exe sometimes in src/interface folder happens when I change the build.sh script. I really do know how it occurs. I built more than ten times. And now it happens every time. Maybe beacuse I upgrade the msys2 or maybe I use make -j8.
Re: Why is the filezilla.exe sometimes in src/interface folder?
Recompile your mingw to use win32 thread model instead of pthread/posix.1)how to make libwinpthread-1.dll static link
i686-w64-mingw32-gcc -v must print "Thread model: win32" instead of "Thread model: posix"
Compile a static zlib before GnuTLS.zlib1.dll
Note that both GnuTLS and wx3 make use of zlib. In your case GnuTLS uses the system zlib whereas your wx uses its built-in copy. Bad things will happen if you have multiple versions of the same library loaded.
Yes.Can I disable nls in gnutls with --disable-nls?
The -static might be troublesome, try without.export EXTRA_LDFLAGS="-static-libgcc -static-libstdc++ -static"
Re: Why is the filezilla.exe sometimes in src/interface folder?
I built win32 thread according to wiki page before.
But the msys2 with Thread model: posix can build filezilla and it seems to work quite well(I mean that if I copy libwinpthread-1.dll with filezilla, I can start filezilla and upload & download via ftp). Is it instability?
But the msys2 with Thread model: posix can build filezilla and it seems to work quite well(I mean that if I copy libwinpthread-1.dll with filezilla, I can start filezilla and upload & download via ftp). Is it instability?
Re: Why is the filezilla.exe sometimes in src/interface folder?
No. It's whether to have to link against that dll or not.rexdf wrote:I built win32 thread according to wiki page before.
But the msys2 with Thread model: posix can build filezilla and it seems to work quite well(I mean that if I copy libwinpthread-1.dll with filezilla, I can start filezilla and upload & download via ftp). Is it instability?
Re: Why is the filezilla.exe sometimes in src/interface folder?
Now my build has only one libwinpthread-1.dll needed. ( I think gnutls bring in it.)
If I filezilla cannot find libwinpthread-1.dll, it complains about `Program cannot start as normal 0xc000007b. Click Ok to close program.` It is a bit different from libpng16-16.dll libtasn1-6.dll etc which will tell me `cannot find entry point on libtasn1-6.dll`
I use dependency Walker to find out.
filezilla.exe --> LIBWINPTHREAD-1.DLL
clock_gettime, (I think GnuTLS)
pthread_cond_broadcast,pthread_cond_wait,pthread_getspecific,pthread_key_create,pthread_mutex_destroy,pthread_mutex_init,pthread_mutex_lock,pthread_mutex_unlock,pthread_once,pthread_setspecific. (I think filezilla and wx3)
If I filezilla cannot find libwinpthread-1.dll, it complains about `Program cannot start as normal 0xc000007b. Click Ok to close program.` It is a bit different from libpng16-16.dll libtasn1-6.dll etc which will tell me `cannot find entry point on libtasn1-6.dll`
I use dependency Walker to find out.
filezilla.exe --> LIBWINPTHREAD-1.DLL
clock_gettime, (I think GnuTLS)
pthread_cond_broadcast,pthread_cond_wait,pthread_getspecific,pthread_key_create,pthread_mutex_destroy,pthread_mutex_init,pthread_mutex_lock,pthread_mutex_unlock,pthread_once,pthread_setspecific. (I think filezilla and wx3)
Last edited by rexdf on 2015-05-02 17:40, edited 2 times in total.
Re: Why is the filezilla.exe sometimes in src/interface folder?
The following two links seem to talk about it. But I don't know to pass in -Wl,-Bstatic -lpthread to configure
http://stackoverflow.com/questions/1376 ... l-in-mingw
http://sourceforge.net/p/mingw-w64/mail ... /31213279/
http://stackoverflow.com/questions/1376 ... l-in-mingw
http://sourceforge.net/p/mingw-w64/mail ... /31213279/
Re: Why is the filezilla.exe sometimes in src/interface folder?
-static-libstdc++ bring in the LIBWINPTHREAD-1.DLL.
i686-w64-mingw32-g++ -std=c++11 test.cpp
LIBWINPTHREAD-1.DLL LIBGCC_S_DW2-1.DLL LIBSTDC++-6.DLL (KERNEL32.DLL MSVCRT.DLL)
i686-w64-mingw32-g++ -std=c++11 -Wl,-Bstatic -lstdc++ -lpthread test.cpp
LIBGCC_S_DW2-1.DLL (KERNEL32.DLL MSVCRT.DLL)
i686-w64-mingw32-g++ -std=c++11 -static-libgcc -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread test.cpp #<--- here
LIBWINPTHREAD-1.DLL (KERNEL32.DLL MSVCRT.DLL)
i686-w64-mingw32-g++ -std=c++11 -static-libgcc -Wl,-Bstatic -lstdc++ -lpthread test.cpp #<-- and here
(KERNEL32.DLL MSVCRT.DLL)
i686-w64-mingw32-g++ -std=c++11 -static test.cpp
(KERNEL32.DLL MSVCRT.DLL)
i686-w64-mingw32-g++ -std=c++11 -static-libgcc -static-libstdc++ -static test.cpp
(KERNEL32.DLL MSVCRT.DLL)
Code: Select all
// mutex example
#include <iostream> // std::cout
#include <thread> // std::thread
#include <mutex> // std::mutex
std::mutex mtx; // mutex for critical section
void print_block (int n, char c) {
// critical section (exclusive access to std::cout signaled by locking mtx):
mtx.lock();
for (int i=0; i<n; ++i) { std::cout << c; }
std::cout << '\n';
mtx.unlock();
}
int main ()
{
std::thread th1 (print_block,50,'*');
std::thread th2 (print_block,50,'$');
th1.join();
th2.join();
return 0;
}
LIBWINPTHREAD-1.DLL LIBGCC_S_DW2-1.DLL LIBSTDC++-6.DLL (KERNEL32.DLL MSVCRT.DLL)
i686-w64-mingw32-g++ -std=c++11 -Wl,-Bstatic -lstdc++ -lpthread test.cpp
LIBGCC_S_DW2-1.DLL (KERNEL32.DLL MSVCRT.DLL)
i686-w64-mingw32-g++ -std=c++11 -static-libgcc -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread test.cpp #<--- here
LIBWINPTHREAD-1.DLL (KERNEL32.DLL MSVCRT.DLL)
i686-w64-mingw32-g++ -std=c++11 -static-libgcc -Wl,-Bstatic -lstdc++ -lpthread test.cpp #<-- and here
(KERNEL32.DLL MSVCRT.DLL)
i686-w64-mingw32-g++ -std=c++11 -static test.cpp
(KERNEL32.DLL MSVCRT.DLL)
i686-w64-mingw32-g++ -std=c++11 -static-libgcc -static-libstdc++ -static test.cpp
(KERNEL32.DLL MSVCRT.DLL)
Re: Why is the filezilla.exe sometimes in src/interface folder?
Done. -static-libgcc -Wl,-Bstatic -lstdc++ -lpthread -Wl,-Bdynamic can remove dependency on libwinpthread-1.dll.
Now my build on msys2 has no extra dll dependency. Can I make a wiki page?
PS: Why is the toolbar icon a bit different from offical build?
Now my build on msys2 has no extra dll dependency. Can I make a wiki page?
PS: Why is the toolbar icon a bit different from offical build?
Re: Why is the filezilla.exe sometimes in src/interface folder?
Of course, that's what wikis are there for.Can I make a wiki page?
Different theme. See Themes page in settings dialog of FZ.PS: Why is the toolbar icon a bit different from offical build?
Re: Why is the filezilla.exe sometimes in src/interface folder?
New wiki page: https://wiki.filezilla-project.org/File ... a_on_msys2
Build as https://wiki.filezilla-project.org/Comp ... er_Windows will fail.
We need to patch two files.
c:\msys\mingw64\x86_64-w64-mingw32\include\shlobj.h
c:\msys\mingw\i686-w64-mingw32\include\shlobj.h
Line 9 to 11:
The latest mingw-gcc git source code:
http://sourceforge.net/p/mingw-w64/ming ... e/shlobj.h
I have changed the wiki page.
Build as https://wiki.filezilla-project.org/Comp ... er_Windows will fail.
We need to patch two files.
Code: Select all
checking for whether we need -stdlib=libc++... no
checking for whether we can include <unordered_map>... yes
checking shlobj.h usability... no
checking shlobj.h presence... yes
configure: WARNING: shlobj.h: present but cannot be compiled
configure: WARNING: shlobj.h: check for missing prerequisite headers?
configure: WARNING: shlobj.h: see the Autoconf documentation
configure: WARNING: shlobj.h: section "Present But Cannot Be Compiled"
configure: WARNING: shlobj.h: proceeding with the compiler's result
configure: WARNING: ## ---------------------------------------------- ##
configure: WARNING: ## Report this to tim.kosse@filezilla-project.org ##
configure: WARNING: ## ---------------------------------------------- ##
checking for shlobj.h... no
configure: error: shlobj.h not found which is part of the Windows API
c:\msys\mingw\i686-w64-mingw32\include\shlobj.h
Line 9 to 11:
Code: Select all
#include <wtypesbase.h>
#include <wincrypt.h>
#include <winapifamily.h>
http://sourceforge.net/p/mingw-w64/ming ... e/shlobj.h
I have changed the wiki page.
Re: Why is the filezilla.exe sometimes in src/interface folder?
I've overhauled the wiki pages for compiling under Windows. msys2 is now the recommended build environment to use under Windows.
I managed to get rid on the dependency on libwinpthread.dll via some other crude means. Libtool is such a great tool...
Unfortunately libtool reorders the arguments. It moves the -lstdc++ argument away from the -Wl,-Bstatic-static-libgcc -Wl,-Bstatic -lstdc++ -lpthread -Wl,-Bdynamic can remove dependency on libwinpthread-1.dll.
I managed to get rid on the dependency on libwinpthread.dll via some other crude means. Libtool is such a great tool...