I need the library Cyrus SASL as a static library on Windows (https://cyrusimap.org/mediawiki/index.php/Downloads#SASL_Library)
How to do that ?
As far as I know, you will need a MinGW and MSYS environment and then just build the SASL from sources like it were on Unix-like, i. e.
./configure
make
make install
You will get some *.a files -- those are static libraries, built with MinGW, they should work for Windows.
I'm still checking this topic, so I'll add some more info if I'm done with it.
For more reference about building projects from sources check the INSTALL file in your project's root directory, i. e. cyrus-sasl-<version>/INSTALL
upd: this seems to be not an easy thing to do, check out this article
upd2: if you prefer Visual Studio, you could check this rather outdated howto.
upd3: in general good article from GNU
Related
I want to run an application based on Qt5 shared objects.
Although I have apt installed qt5-default, qttools5-dev and qttools5-dev-tools I get the error bellow:
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.7' not found
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5' not found
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5: version `Qt_5' not found
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5: version `Qt_5' not found
I have also tried to change some environment variables as LD_LIBRARY_PATH and DYLD_LIBRARY_PATH, resulted in no success!
What do you suggest?
When you built your application, which version of Qt5 did you build against? You can see this in QtCreator by looking at the currently selected kit:
If you just installed QtCreator from binary, it is shipped with it's own set of Qt5 shared libraries that your application is linked against, however your OS' version of those libraries (those installed from apt-get and similar) may not match.
When you try to run the application on it's own outside QtCreator, it may try to link against the OS version of the libs which are usually much older.
There are many ways to resolve this. One way, which would be preferred if you don't care for the newest version of Qt, is simply building towards the Qt libs supploed by the OS. You can do this by creating a new kit that specifies to build against the OS' libraries following this procedure.
Another way is shipping the shared libraries that you used from QtCreator together with the application so that those will override the OS ones. Usually just chucking them into the same folder as the executable will do the trick, as they will be found before the ones under /usr/lib/whatever etc.
Yet another way is to build your own static version of Qt and link with that. This has some benefits and some drawbacks. This is an advanced topic, so I won't go into detail (you can see here). But in this case the Qt libs are built into your app and will not depend on any external Qt libs version.
I am using the MinGW-w64 installer found here:
https://mingw-w64.org/doku.php/download/mingw-builds
Installing to a directory creates a folder called mingw32 or mingw64 that contains the compiler. I already know that the additional batch script, HTML link, and uninstall executable in the same directory can be deleted.
The mingw32/64 folder contains these folders:
bin
etc
include
lib
libexec
licenses
opt
share
i686-w64-mingw32 (mingw32) or x86_64-w64-mingw32 (mingw64)
I only wish to compile with C and nothing else. So what files can I delete in order to reduce the file count because the compiler contains files for Ruby, Fortran and other languages which as I stated, I don't need it.
Why are people still using Mingw or Mingw64 instead of TDM-GCC ? You have to rely on the default builds or build it yourself from source. Trying to install it on your own terms sucks.
TDM-GCC on the other hand, you can specify where and which components to install as you wish. You can upgrade or remove it without any worries. It's more fast, easy,modern and equivelant these days.
Now for your question, you can download and install TDM-GCC by it's installer. I don't really think you need any further instructions as a 5 year old would understand how to use it. Just select only the components required for c.
If you don't understand,I would gladly help you more if needed. ^_^
If you want a smaller GCC toolset, try MinGW Distro.
Scroll down to "How To Build Your Own Distro", download components-14.1.7z, extract it, extract binutils 2.27 and GCC 6.3.0 inside the same folder. The total size is about 270MB.
as far as i know the minimum are yours
1, bin
5. libexec
not all tools in bin you may need but generally i would hold both of those dirs
you also ned libraries and headers if you want to build abainst standard c library and windows.h, so
include
lib
is also needed (hovever part of it may contain also headers and libraries for c++ standard library) all those main 3 libs are kinda mixed there afaik so it might be a bit hard to find what comes for what
I am using the cmake to build my project. However, I need to build this project on a machine that I do not have the permission to install any software on it. I thought I can use the generated makefile but it has the dependencies on CMake,and says cmake:command not found.Is there any solution that force the generated makefile do not have any cmake related command such as check the system version? Thanks
Is there any solution that force the generated makefile do not have any cmake related command such as check the system version?
No. There is no incentive for cmake to provide such an option, because the whole point of the cmake system is that the cmake program examines the build machine and uses what it finds to generate a Makefile (if you're using that generator) appropriate to the machine. The generated Makefiles are tailored to the machine, and it is not assumed that they would be suitable for any other machine, so there is no reason to suppose that one would need to use one on a machine that does not have cmake. In fact, if you look at the generated Makefiles you'll find all sorts of dependencies on cmake.
Depending on the breadth of your target machine types, you might consider the Autotools instead. Some people dislike them, and they're not a good choice if you want to support Microsoft's toolchain on Windows, but they do have the advantage that an Autotools-based build system can be used to build software on machines that do not themselves have the Autotools installed.
one easy solution is to use static libraries and the 'static' parameter in the command line.
Then you should be able to drop the executable on the target machine and run it.
I have a project that links to libssl.so and I'm hitting a bug in libssl and never versions of the lib fixes it. However on the system I'm working I don't have root account so I've built libssl and prerequirements myself under $HOME/opt.
Now, when I'm doing:
./configure --prefix=`$HOME/opt`
make
the build system still uses the older system-wide version of libssl.
I'm trying to find the proper way to "hack" autotools to link with libs I've compiled.
I'm not sure, but perhaps you should also add the new path to the PKG_CONFIG_PATH. That is, if your project uses PKG_CHECK_MODULES for finding libssl.
There's always ./configure LDFLAGS=-L$HOME/opt/lib CPPFLAGS=-I$HOME/opt/include. But that method globally uses headers from that prefix and globally links against libs located there.
Many projects provide AC_ARG_WITHs to allow to customise paths, e.g.
AC_ARG_WITH([ssl], ...)
or
AC_ARG_WITH([ssl-prefix], ...)
AC_ARG_WITH([ssl-libs], ...)
AC_ARG_WITH([ssl-includes], ...)
in analogy to autoconf's --x-includes and --x-libraries
But I guess it's a question of personal taste.
Just noticed you don't want to change your files, in that case you could just add the library in question to the the LIBS variable, or use an rpath:
./configure LIBS="$HOME/opt/lib/libssl.so.x.y.z"
or
./configure LDFLAGS="-Wl,-rpath,$HOME/opt/lib/"
It seems that:
LDFLAGS="-L$HOME/opt/lib" ../configure --prefix="$HOME/opt"
is forcing autotools to try $HOME/opt/lib first. If anybody knows better or more general answer I'm still all ears.
I want to build a static library (*.LIB file) GNU libiconv on windows to be used with other libraries in Visual C++. Other libraries I'm using are built with "MultiThreaded DLL" (/MD) Runtime option. So, I need to build libiconv with the same option.
Problem is the libiconv uses GNU build system and I want to compile with /MD option. You can see the source structure of libiconv here:
http://cvs.savannah.gnu.org/viewvc/libiconv/?root=libiconv
Mr. Zlatkovic maintains the windows port of GNU libiconv for libxml2
you can see them here:
ftp://xmlsoft.org/libxml2/win32/iconv-1.9.2.win32.zip
I cannot use his port. I need to build from the latest version of libiconv-1.13. I wonder how this guy has ported it? Can some one please tell me how to build *.lib from this and compile it using MSVC?
EDIT:
Actually, I need to build few more gnu libraries with same settings. So, if I get solution for one library. I can do the same for all others.
I found PARK Youngho's How to Build libiconv with Microsoft Visual Studio over at The Code Project to be complete and clean (for VS2010 and GNU libiconv 1.14).
A little addition to your answer.
I had the same issue and found that the MinGW + MSYS solution was perfect.
Though, I needed to go a little further and generate also the .lib file in order to be able to link with the resulting dll.
This is what I found:
generate a .def file from the dll with dumpbin (a Visual Studio tool).
generate the .lib file from the .def with the lib program (Visual Studio tool too)
This allows you to specify some link flags if appropriate.
Everything detailed here (I'm not the author of this method):
http://wiki.videolan.org/GenerateLibFromDll
I also realized that this lib/dll couple can be linked with both MD and MDd libraries.
Hope that can help people that find this post, like it helped me.
-David
I'm the OP. MSYS is the exact thing what I was looking for.
Just install MinGW & MSYS which contains shell sh.exe & make.exewith which you can configure and generate a Makefile after that you can use make.exe to run it.
Its as simple as that.
compile them using MinGW using Msys for the environment if needed. MinGW's .a files are apparently, according to the mailing list, the same format as .lib files (just do a rename). You might want to check first to see if the iconv static library is included already in the MinGW download / filesystem.
Edit: it's in msys (C:\msys\1.0\lib), along with:
libiconv.a
libiconv.dll.a
libiconv.la
and additionally
libiconv-2.dll (in C:\msys\1.0\local\bin)
Edit: is it in here, the libiconv you need? these versions seem to have MSVC makefiles :) http://www.opensource.apple.com/source/libiconv/