I'm looking for 64-bit static Windows libraries for gettext. Eveything I can find says to get them at https://mlocati.github.io/articles/gettext-iconv-windows.html. That page has links to download the static libraries for both 32-bit and 64-bit, but the zip file doesn't actually contain any libraries, just a bunch of executables.
Any suggestion?
Related
I noticed that deployed on windows Qt applications are always including the dlls they needed.
Why did they made it that way?
Why can't they do it like on linux? - You install needed Qt version to system, and then every application that need it - can use it, e.g. only one instance of libraries(excluding different versions like qt4/qt5).
Wouldn't it be better to make it like Java/.Net, e.g. you install Java/.Net then you run/develop applications using only one instance of libraries(dlls).
I find it kinda "unconservating": I have 7 applications that use Qt5, and all of them have Qt5Core.dll, Qt5GUI.dll, etc. and every of them takes some space. Feels like I have 7 packs of Qt5 libraries... x_x
While on linux these same applications use only "one" Qt library.
I noticed that deployed on windows Qt applications are always including the dlls they needed.
This is called "local deployment".
Why did they made it that way?
I can think of a few reasons.
To avoid DLL Hell.
It is sanctioned by Microsoft. They wrote, "You can use this deployment method to enable installation by users who don't have administrator rights, or for applications that can be run from a network share." (see https://learn.microsoft.com/en-us/cpp/windows/choosing-a-deployment-method?view=vs-2019)
You install needed Qt version to system, and then every application that need it - can use it, e.g. only one instance of libraries(excluding different versions like qt4/qt5)
Qt is a C++ library. C++ DLLs can differ by more than just a major version number. The DLLs could be built with MinGW, or they could be built with MSVC; They could be 32-bit, or they could be 64-bit. The different variants are incompatible with each other.
Example: if you force a PC to have one global copy of Qt 5.14.1 MSVC 32-bit and put that in your PATH, then:
Other Qt apps on that PC that are built with MinGW cannot run.
Other Qt apps on that PC that are 64-bit cannot run.
Apps that must use Qt 5.13 might be broken. (For example, if a critical bug exists in Qt 5.14)
Why can't they do it like on linux? .... on linux these same applications use only "one" Qt library.
I listed a few disadvantages of this approach above. In addition, the version of Qt in Linux distros are usually a few versions behind so applications in the distro repository cannot make use the latest features, bugfixes, or improvements.
That's part of the reason why systems like AppImage and Snapcraft were invented. Sometimes, Linux users also want an app to contain a copy of its libraries, instead of having a single global copy of the libraries.
The Windows binary distribution of the Linaro gnu AARCH64 ARM cross compiler (based on mingw) has a dependency on a library libwinpthread-1.dll. When I run .\aarch64-elf-gcc.exe --version I get a pop-up that says
The program can't start because libwinpthread-1.dll is missing from your computer. Try reinstalling the program to fix this problem.
For the life of me I can't seem to find anything about this library, where to find it, build it, etc. Based on the name it seems obvious that it is some pthread library for windows, but maybe not. The cross compiler is a 32-bit Windows binary for a 64 bit ARM target. The host is 64-bit Windows 10.
Any idea where I can find a 32-bit version of libwinpthread-1.dll?
The latest version of the tool chain at
https://releases.linaro.org/components/toolchain/binaries/6.1-2016.08/aarch64-elf/
seems to not have this problem of a missing dll
It can be found in
gcc-linaro-6.1.1-2016.08-i686-mingw32_aarch64-elf\libexec\gcc\aarch64-elf\6.1.1\libwinpthread-1.dll
Ed
I need to install a DLL on Windows and OSX, it will be used by several apps and dlls placed allover the system, but I'm 100% sure it will always be my apps and I don't need any kind of versioning, meaning that if the DLL is replaced by a newer version (or older for that matter), it will work just fine. I also need 32-bit and 64-bit versions.
It looks like these are the proper paths:
OSX : /usr/lib (merged binary for 32 & 64)
Windows: C:\Windows\System32 (here the sources vary)
On OSX it seems working fine. On Windows however it doesn't. I need to support Windows XP,7,8... And on Windows 8.1 it sometimes just didn't work - the file was clearly there, but systém said the DLL is missing. It also seems like the folder for 32-bit (SysWOW64) and 64-bit (system32) are actually pointing to the same location, so I assume Microsoft has been "fixing" the naming mess.
Anyway one location it always worked is here:
C:\Windows
but it doesn't seem to be designed for that. So how is it?
We have a C++ / Objective C based app.
We use LLVM-GVC compiler to compile our code.
Currently we build 32-bit binaries and deploy them on our customer's machines.
We support SnowLeopard, Lion, Mountain Lion and Mavericks.
I'm aware that all these are 64 bit OS. They can run 32 bit binaries fine.
But i want to know, going forward , is it a better idea to deploy 64bit binaries of my app?
I can compile our code base and build 64 bit binaries, but i will have to link against 3rd party 64bit libraries etc.
I think its do-able.
My question is what are the advantages of deploying 64 bit binaries, provided that 32binaries still work on these OS's?
Also what bout Universal Binary? Do you guys think building a Universal Binary would be a better option? If yes, why?
I'd appreciate any thoughts/suggestions.
If your binaries are standalone apps, as in they're not plugins or dylibs for other programs, then there's nothing wrong with using 32-bit binaries. You're in good company; if you look at Google's Chrome browser, that also uses 32-bit binaries.
The advantage of 64-bit is that you can address more memory, if required and I think there are a few assembler instructions that are faster with 64-bit instructions, but overall, if it works for you, I don't believe it's an issue.
If you find yourself creating a dylib that must work with both 32 and 64 bit applications, that would be a reason for creating a Universal Binary, to save having to create one of each and work out which you need at runtime; with a Universal Binary OSX will take care of that for you.
I like to use command line to install Tomcat as a Windows service. There should be the service.bat file for this purpose. But it is missing from Tomcat 7.0.37 and 7.0.39.
We can not use Windows installer for embedded, so this is not an option.
Thanks for help.
Are you sure you have downloaded the right package?
From the download page for the latest Tomcat 7 version (7.0.39 at the moment of writing this) choose depending on your needs:
32-bit Windows zip
64-bit Windows zip
Both packages have service.bat in the bin directory.
Also on the download page read the README file for packaging information. It explains what every distribution contains.
UPDATE
From the README file for packaging information (emphasis mine):
apache-tomcat-[version].zip or .tar.gz
Base distribution. These distributions do not include the Windows service wrapper nor the compiled APR/native library for Windows.
apache-tomcat-[version]-windows-x86.zip
32-bit Windows specific distribution that includes the Windows service wrapper and the compiled APR/native library for use with
32-bit JVMs on both 32 and 64 bit Windows platforms.
apache-tomcat-[version]-windows-x64.zip
64-bit Windows specific distribution that includes the Windows service wrapper and the compiled APR/native library for use with
64-bit JVMs on x64 Windows platforms.
You may also find it useful reading the RUNNING.txt file, which is available in every distribution. It contains important details about installing/configuring/running Apache Tomcat and also Windows and *nix specific instructions.
Tomcat is a Java application. So it is cross-platform. But if you want/need to utilize Windows specific features, like Windows services in your case, then you should download the Windows specific distribution.
Other thoughts
I myself on my Windows machine use "Base distribution" (i.e. not Windows specific, but an ordinary ZIP file available on the download page under Binary Distributions => Core) without any problem whatsoever, because I prefer not to bother with installations (i.e. running the installer), but just to simply unpack the distribution to the desired directory and manually configure it using the related config files. It's so much easier and convenient both to install (just unpack) and delete the installation (just delete without running any uninstaller), and it's more portable. Plus this way you can install multiple versions of Tomcat on the same machine (in case you need this for some development/testing reasons).
Here is a very useful step-by-step tutorial with some nice illustrations and explanations:
How to Install Apache Tomcat 7/8 (on Windows, Mac, Ubuntu) and Get
Started with Java Servlet
Programming
In the official web site, under core. Don't download the version tagged zip. Download the version tagged 32-bit Windows zip or 64-bit Windows zip. You will find Service.bat under Bin