All I need is get MinGW talking to Postgres. I've considered several options:
Use libpq. The libpq.lib that comes with Postgres for Windows links okay, but crashes when I use the library. I think because it was compiled for VC++. I can't find just the libpq code, so I'd have to recompile the entire Postgres tree in MinGW. Not easy.
Use libpqxx. Requires libpq!
Use libodbcxx. Requires some sort of ODBC manager like iodbc. Maybe I can use iodbc directly. Since this is just Windows for now can I use -lodbc on my linker and use some Windows specific commands?
Option 1 sounds the least painful. I'm pretty sure the project will use Postgres, not too sure if the project will stay on Windows. Is there a simple way to get this functionality?
You can rebuild just libpq if you have to. Run "./configure" and then run "make" in just src/interfaces/libpq.
But really, the msvc built libpq should work just fine with mingw. It's just a standard Windows DLL. It may be an issue with the .lib - but the DLL should be fine. AFAIK, only the PQtrace() functionality will be broken - because of the way MSVCRT works, that only works if you have the exact same version of the runtime.
You should also be able to generate an import library directly off the DLL, if the .LIB doesn't work. Or does MingW even allow you to link directly to the DLL - see their wiki
Getting libpq to work is likely a lot easier than odbc.
As you also asked R questions here, I assume you can manage to read source to R packages. The RPostgreSQL package does exactly what you are after:
It uses MinGW as all R binaries and packages on Windows are built with MinGW
It links to libpq to talk to Postgres
The file src/Makevars.win simply has
PKG_CPPFLAGS=-I"${PG_HOME}"/include
PKG_LIBS=-L"${PG_HOME}"/lib -llibpq
which tells R where the Pg headers and library are, and then links with libpq.
A side-note... Your CXXFLAGS and LDFLAGS for compiling and linking to the Postgres files can be setup easily using the following variables in your Makefile:
CXXFLAGS += -I$(shell pg_config --includedir)
LDFLAGS += -L$(shell pg_config --libdir) -llibpq
(Provided you have included the bin folder that contains pg_config.exe of your PostgreSQL installation on your system's PATH and that you use mingw32-make.)
Related
I am asking here because I couldn't get any support elsewhere. Also consider that I am quite a beginner so bear patience.
I am using Winlibs (winlibs.com, a ready to use mingw gcc10+ distribution) to code under Windows because after having tried other alternatives I judged it the best to my purposes, easiest to install and the most functional. I never had any problems with it.
But recently I had the need of writing some simple code to send a POST request. I wanted to do it in a possibly portable and c++ friendly manner, so I was suggested to use Curl. No libcurl is included in winlibs so I tried to load one from here
https://curl.se/download.html
I chose the windows 64 binary of course (7.83.1) since I am working on windows 64 with winlibs 64. I installed everything in the right place and linked against libcurl.a.
Unfortunately the linker complains of unresolved symbols so I have to supppose the curl binaries I used are not suitable.
How can I use libcurl with winlibs then ? Before bothering here I really googled but could find no info!
The MinGW-w64 tools from https://winlibs.com/ are only a build toolchain, so they don't contain libraries for you to link with (yet).
You need a Windows build of libcurl and use that.
To use it you must include the location to the header files using the -I compiler flag, and then link with the library by pointing to the location of the .a file with the -L linker flag and then link with the library using the -l flag (-lcurl in this case). If you don't have .a files you can also try to link with the full path of the .dll file and gcc will know it's a shared library.
An easier way is to get libcurl via MSYS2's pacman package manager.
If you want to statically link you need to use the output of pkg-config --static --libs libcurl as link flags.
In practice though I noticed that sometomes pkg-config --static --libs libcurl is missing some dependencies and you still need to add some manually. An example of a project of mine that builds on Windows with winlibs MinGW-w64 (both 32-bit and 64-bit) can be found at https://github.com/brechtsanders/winlibs_tools/blob/main/Makefile (specifically look for the definition of CURL_LDFLAGS)
Ok, so, I'm trying to build a third party library with msys2 and I've run into a problem with a few headers, such as gtk.h; the library I'm trying to build expects this to be located via #include <gtk/gtk.h>.
Now, experience on Linux tells me that would be correct under a normal linux environment; however, in the case of gtk, it seems it would have to be gtk-3.0/gtk/gtk.h, which seems like an error in msys to me - is there some sort of selection step I've missed in setting up my msys2 environment? Like the 'eselect' system under Gentoo, something like 'pselect gtk-3.0' that would create a linked directory to gtk-3.0/gtk just called gtk?
Assuming that you have installed the mingw-w64-i686-gtk3 package with pacman and that you are running in a MinGW 32-bit shell (MSYS2 has three different flavors of shell that use different toolchains), you can run this command to get the required compile flags for GTK3:
pkg-config gtk+-3.0 --cflags
Most build systems have some kind of support for calling pkg-config. It is basically the standard way to get information about your dependencies.
When it's time to link your program, you should replace --cflags in the comand above with --libs.
You simply need to tell the compiler where to find the include directory:
-I/some/path/to/gtk-3.0
This may be obvious, but I want to make sure what to do before I do anything rash. I want to compile my C++ program, libraries and all, to a release executable such that the file can be run on any computer (running the same OS). Right now, I'm on Mac OS X (10.7.4) and I need to be able to run my executable on other Macs. The problem is I am using the OpenCV library in my project, and I only have it installed on this computer. Is there a way to compile with g++ such that if I open this program on a computer that doesn't have the OpenCV library installed, it will work anyway? As in, build all the dependencies into the executable. Or does this happen automatically?
I am also quite new to the ".o" object files, so can those have anything to do with it? I would prefer a way to get it all into a single file, but I'll settle for a package as long as it works.
Thank you.
To expand on molbdnilo's answer, you'll need to create an application bundle (see the Apple Bundle Programming guide). You'll need to move your console application to MyApp.app/Contents/MacOS/MyApp. There's also a Frameworks directory in which you'll need to add the OpenCV library as a framework. See the OpenCV Wiki for some information on the OpenCV framework. A framework (at its simplest) is pretty much a dynamic library wrapped in a particular directory structure.
I would suggest looking into using Xcode on the mac as it simplifies the construction of bundles and linking to frameworks compared to doing it yourself via scripting and Makefiles.
There are two ways to do this. You can static link if you aren't going to run into licensing issues with any of the libraries you are linking to. This is pretty easily handled by using g++ -o myApp -static -lopencv myapp.cpp However, this also depends on static libraries existing for the libraries you want to link to. Most distribute static libs with the shared libs these days.
The other way is to distribute the shared libraries and tell your application to force it to look in a certain spot for the shared library using -rpath. Note: I am telling you the Linux way to do this, it will probably work on a Mac but I have no way to test.
So say all of your shared libraries are in the same directory as your executable, you can compile with: g++ -rpath ./ -lopencv -o YourApp yourApp.cpp
I hope this helps.
I have been using a socket library for C++. Some other info: 32 bit Linux, Codelite and GCC toolset. I want to be able to compile my program for Windows using the windows edition of Codelite. The socket library I have been using doesn’t have a mingw32 build of the library, but it’s open source. So how can I make a mingw32 build of the socket library so I can make a windows build using the source provided?
Most open source linux libraries are built with the make build system (although there others like jam etc, and custom written scripts for building). MinGW comes with the make utility, it's mingw32-make.exe. It may be possible (if you're lucky) to simply rebuild your library by making it on Windows.
The more usual scenario is that you will need to configure the project before you can build it though. The windows shell doesn't support the scripting requirements required to configure, but there's another part of the MinGW project that does called MSYS. If you install msys and all the required tools you need for it, you'll be able to ./configure your project before running make.
Of course, the above will only work if the library is written to be portable. There are some breaking difference between the linux socket implementation (sys/socket.h), and the windows implementation (winsock2.h). You may be forced to edit chunks of the code to ensure that it is versioned correctly for the platform (or that any dependencies required are also built for Windows).
Also, there is the chance that the library may already be built for Windows, but using a different compiler like MSVC, which produces .lib and .dll files. Mingw requires .a files for libraries, but a clever feature is the ability to link directly against a .dll, without the need for an imports library, so you can often use an existing windows library that was not built against Mingw (Although this won't help for static linking). There is also a tool, dlltool, which can convert .lib to .a.
If you give detail on the specific library you're working with, I may be able to pick out for you what needs to be done to run it on Win.
You port it to the new platform. :)
You're fortunate that it is opensource, because then it would be practically impossible to port it (You'd have to pay $$$'s to get a copy of the code for a particular license, or rewrite the entire product).
Enjoy.
Alternatively, they may well already have a port... Check the documentation for the library you are using.
First off your going to need to make sure that you aren't including any Linux specific libraries.
I made a program on Mac OS X using OpenGL and dynamically linking libpng. I'm now trying to port it to Windows. Whenever I try to compile and link my ported program in Borland it gives me this error and about 10 more that are the same, but with a different '_png_create_read_struct':
Error: Unresolved external '_png_create_read_struct' reference from C:\PROGRAMMING\PNGTEST.OBJ
I assume it's because I have not properly set up libpng with Borland C++ 5.5.1 for Win32. I've put png.h and pngconf.h into the include folder into C:\Borland\BCC55\Include, and I have put libpng12.dll.a, libpng13.a, libpng13.dll.a, libpng.a, libpng.dll.a, libpng12.def, libpng.def, libpng12.la, and libpng.la into C:\Borland\BCC55\Lib (there is probably no need for them all, but as a noob I have no idea which ones are needed and not).
Do I need to put a libpng.obj file in there too? And if so how would I make/get one? I have tried using makefile.bc32 to set up libpng, yet that gives me a missing separator error.
Here are my command-line options:
bcc32 -tW pngtest.cpp -lpng
I include png.h in my code. What am I doing wrong or is there an even better way to load images with alpha that doesn't need libpng, or even a better compiler to get for Windows?
You're probably better off with the MinGW compiler than Borland. Borland is not well supported any longer.
You could also download DevC++ and see if it has a libpng package in its addon mechanism.
DevC++ is an IDE that uses the MinGW C/C++ compiler.
That said, if you feel you must use BCC, you'll either have to
a) Build libpng with Borland. This is the best solution if you're going to use borland.
b) Use, I think, Impdef to create an import library from libpng.dll. You'll find impdef.exe or imp(something).exe in the borland bin directory.
Note that some libraries will not work with impdef as there is static code linked to the dll that causes it to fail without the proper runtime.
First of all, I would not have "polluted" the BC55 installation with third-party libraries; it will make moving the project to other build environments much more difficult. It would have been better to place them in a folder within your project.
Secondly do you know that the export library you are attempting to link is built for BC55? The .a extension suggests a GNU library (Borland libraries conventionally use .lib extension), in which case it would not link with BC55 which uses a different object file format. If this is the case you will need to rebuild the library as you attempted to do, so I suggest that you should really be asking a question about the problem you had with doing just that. I wonder whether the makefile is written for Borland make or GNU make, since they have differing syntax?
The command line option -lpng might be correct for GCC (where it will link libpng.a), but is meaningless to BCC. The -l option merely passes the text that follows to the linker. The linker command line, requires that the complete name be passed, and if no extension is provided, .lib is added implicitly.
You should probably just use coff2omf to convert the library. The DLL files are almost certainly in "Microsoft" COFF format.
See COFF2OMF.EXE, the Import Library Conversion Tool.