I've been trying to properly add the open source dns_sd.h library provided by Apple. I am writing a program that uses the BonjourRegistrar class as demonstrated here:
link text
I've already written my program on the Mac environment and now I am trying to port it to Windows. The Bonjour SDK comes with several classes, and I am quite confused onto how to correctly add the class to my Qt project. I have tried add the line:
win32:LIBS += c:\dnsssd.lib
in the .pro file with no success. Also, I attempted to add the dns_sd.h and dns_sd.c files into my project and got a couple of errors such as:
'UINT8': does not name a type
'INT8': does not name a type
'UINT16' does not name a type
'INT16' does not name a type
Finally, I am now trying to modify the lib file as described by xcimo in this link
link text
I do not know if I am using the correct command to properly modify these files.
The .lib distributed by Apple can be used only if you are compiling the Qt application with the MSVC compiler.
Otherwise, like you said, you need a GCC-compatible library (.a). To do that you need to do the following steps:
Run the reimp tool [0] on the .lib: reimp dnssd.lib. A file DLLStub.obj will be generated.
Run the gendef tool [1] on the .dll: gendef dnssd.dll. A file dnssd.def will be generated. The .dll can be obtained from: C:\Windows\System32 if you are using the 32 bit or from C:\Windows\SysWOW64 for the 64 bit version.
Assemble the final .a: dlltool -k -d dnssd.def -l libdnssd.a.
Add the right path int the .pro file, to the newly created library: LIBS += -L"/path/to/the/library/file" -ldnssd
[0] - http://sourceforge.net/projects/mingw/files/MinGW/Extension/mingw-utils/mingw-utils-0.4-1/
[1] - http://sourceforge.net/projects/mingw/files/MinGW/Extension/gendef/gendef-1.0.1346/ - gendef is a better alternative to pexports, because it can convert the stdcall-type libraries from MSVC to the GCC ones, so you can get a proper .def file.
PS: I know the author got it working, but I felt there should be some more detailed instructions on how to get it done -- the information is scattered around the internet.
Try adding
DEFINES += _WIN32
to your project file.
I figured it out, you need to use reimp and dll tool to modify the lib library to a .a
Related
I have been trying to install PDcurses on my Windows 10 machine. The README.md says to run: make -f Makefile to build pdcures.dll in the 'wincon' folder. However when i ran this in Powershell it did not create any .dll, instead creating many .o files.
Then i tried to run 'make -f Makefile.wcc' in Powershell and it returned the error 'makefile.wcc:9: *** missing separator. Stop.' I got similar errors using Makefile.bcc and Makefile.vc.
What am i doing wrong here? Am i supposed to build one of the .c files?
Each of the Makefiles is compiler-specific, as described in the README.md. There's no reason to try Makefiles intended for compilers other than the one you're using.
The Makefile doesn't build a DLL, by default -- only a static library (ending in .a or .lib). PDCurses is a small library, and there's not much benefit in building it as a DLL. But if you want to, that procedure is also described in the README.md. In short:
make DLL=Y
but please read the file for details. Note that, even if you build PDCurses as a DLL, you'll still also need the .a or .lib file to link against.
I never worked with Win-specific programming and today I've decided to figure out this question. I use Cmake and Ninja and to include a resource file, I use the following line in the Cmake config:
add_executable(${PROJECT_NAME} "${CMAKE_CURRENT_SOURCE_DIR}/src/windows/test.res" ${APP_SOURCE_FILES} )
And when I open properties of my app using context menu I don't see any meta data or icon. These ones are described in the .res file, which I try to include.
But if I use non-compiled resource file everything works (.rs). How should I link a .res file with my app?
For compilling res files I use windres by msys2
It looks like I am not only winapi-beginner. I am also a cmake beginner. When a path is added to add_executable Cmake tries to compile a file with the specified path to a .obj file. But because a .res file has been compiled, cmake just does nothing. In this case, I have to add .res file to the link flags instead. Google, thank you. You're the best :)
I have a "cross platform" application that uses two code repositories at the moment, maintained relatively independently, and built with VS / Xcode depending on the target platform (win or mac respectively). I fell in love with Premake after using it on a few previous projects and am trying to pull all of my code for this application together into a single cross-compilable codebase.
I don't want to rely on Xcode, and instead want any developer to be able to build on Mac using either Xcode or gmake. I have a non-standard framework that I want to link to and include in the repository (it won't be located in /Library/Frameworks or any of the default mac framework search paths). I've added the framework file in a directory in my project /lib/TheFramework.framework. My premake file contains the following under the project definition:
includedirs {".", "lib", "lib/TheFramework.framework/Headers"}
libdirs {"lib"}
links {"TheFramework.framework"}
When I compile, (running $ premake5 gmake and then $ make), I get a header file not found error. Is there something wrong with my search paths? Am I missing a path or a flag somewhere?
Thanks!
Before looking at what you need to do with premake, let's first look at what needs to happen under the hood.
When compiling a mac program with a non-standard framework on gcc or clang (which is what your resulting make file does) it is necessary to do two things:
Specify the name of the framework, via -framework TheFramework - This is what premake does when you provide it with links {"TheFramework.framework"
Specify the location of the framework, via -F /Path/To/Framework/ - This is currently not being handled automatically by premake.
I've made a simple test c program that uses the SDL2 framework and compiled it with gcc: https://gist.github.com/JohannesMP/6ff3463482ebbdc82c2e - notice how when I leave off the -F /... flag I get an error that is probably similar to what you described.
So what is happening is, although you are providing premake with the include dir, premake will not add that the proper -F flag.
One way around this is to do the following:
configuration {"macosx", "gmake"}
buildoptions {"-F /Path/To/Framework"}
linkoptions {"-F /Path/To/Framework"}
(See here for an example project: https://gist.github.com/JohannesMP/9a9b5263c127103f1861#file-premake5-lua-L24-L26 )
In premake5 this will blindly append the code provided to both the build step as well as the link step. It is necessary to do it both for build as well as link.
Just keep in mind that, because premake doesn't process or check the build/link options for being valid, a user will receive an error if the provided path doesn't exist on their machine. For example while you might have a framework in your user-specific directory ~/Library/Frameworks, since that folder doesn't exist by default another user might be using the global /Library/Frameworks instead, and when they try to compile your premake project with gmake they will get a warning:
ld: warning: directory not found for option '-F/Users/<NAME>/Library/Frameworks'
At this point, it seems that there is no 'safe' way to get premake5 to try to include the framework path, but that may change in the future.
Check out this issue I posted on the premake repo: https://github.com/premake/premake-core/issues/196
I have tried configuring gtk+ on visual studio but doesn't work properly.,
Can anyone suggest me with a proper solution, as how to install gtk on Visual studio 2010
I got GTK+ working with VS2010, so if you want to get it working too, get ready for some fun, because this will take a few minutes.
First of all, download the latest Windows All-In-One bundle. Optional direct download link for the GTK 2.24 bundle that I used here. The direct link is to the 32bit version. I have not tested the 64bit version because it is still listed as experimental.
Once you have the bundle downloaded, unzip it into something like C:\gtk or in my case D:\gtk
Next we will create a System Environment Variable for the GTK folder. Open up a command prompt and write: setx GTKDIR {Path to your GTK folder} /m which in my case would be setx GTKDIR D:\gtk /m
We are also going to add the .dll files required for GTK+ built applications to run on Windows into our system PATH. To make things very easy, I suggest you edit your system PATH with PathEditor. Now add the path to the GDK binaries folder which in my case is D:\gtk\bin to the system PATH. Confirm the GTK bin folder has been added to the PATH by typing PATH into your command prompt.
Now we move on to Visual Studio 2010 and create a new project.
File
->New
->Project
Visual C++
->Win32
->Win32 Console Application
Then the Application Wizard Appears.
Click to select:
Windows Application
Empty Project
click Finish to proceed.
Before we add any source files, right click on the project name in the Solution Explorer and click on Properties. Now go to Configuration Properties and then VC++ Directories. We now need to add the include and library files from GTK to the Include Directories and Library Directories.
You should have the following in your Include Directories
$(GTKDIR)\lib\gtk-2.0\include
$(GTKDIR)\lib\glib-2.0\include
$(GTKDIR)\include
and Library Directories:
$(GTKDIR)\lib
While we are still in the view of the Project Properties, click on Linker and then System. Look for SubSystem on the right and click the drop down box. Select Windows /SUBSYSTEM:WINDOWS
Next up, we have to generate the flags for the compiler and the linker. Luckily, GTK+ comes with a nice little tool called pkg-config that we will use to automatically generate these flags for us. The pkg-config tool can be found in the bin folder of GTK. In my case this is D:\gtk\bin or %GTKDIR%\bin using our system variable that we defined earlier. Simply navigate to the bin folder(the created text files will be output there) using the command prompt and run the following:
pkg-config --cflags gtk+-2.0 --msvc-syntax > compilerflags.txt
This will create the compiler flags we need and store them in a text file.
My Result for compiler flags (I have removed the flag -mms-bitfields, this is a gcc only flag that we don't need):
-ID:/gtk/include/gtk-2.0 -ID:/gtk/lib/gtk-2.0/include -ID:/gtk/include/atk-1.0 -ID:/gtk/include/cairo -ID:/gtk/include/gdk-pixbuf-2.0 -ID:/gtk/include/pango-1.0 -ID:/gtk/include/glib-2.0 -ID:/gtk/lib/glib-2.0/include -ID:/gtk/include -ID:/gtk/include/freetype2 -ID:/gtk/include/libpng14
We will do the same for the linker flags:
pkg-config --libs gtk+-2.0 --msvc-syntax > linkerflags.txt
My Result for linker flags:
/libpath:D:/gtk/lib gtk-win32-2.0.lib gdk-win32-2.0.lib atk-1.0.lib gio-2.0.lib pangowin32-1.0.lib gdi32.lib pangocairo-1.0.lib gdk_pixbuf-2.0.lib pango-1.0.lib cairo.lib gobject-2.0.lib gmodule-2.0.lib gthread-2.0.lib glib-2.0.lib intl.lib
With all the needed flags generated, we need to add them to our project. Once again, right click on the project name and click on Properties. Now go to C/C++ and click on Command Line. To the right you should see an empty box called Additional Options. Copy and paste the compilerflags.txt content into this box.
After finishing the above, click on Linker and then Command Line. Once again, simply copy and paste the contents of the linkerflags.txt file into the Additional Options box. While we are here, add one last linker flag /ENTRY:mainCRTStartup This flag tells Visual Studio that we want to use the standard main() rather than Microsoft's _tmain() as our main program entry point.
Finally, in the Source Files folder, create and add a new .cpp file with the following:
#include <gtk-2.0\gtk\gtk.h>
int main(int argc, char* argv[])
{
gtk_init(&argc, &argv);
GtkWidget* window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_widget_set_usize(window, 300, 200);
g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(gtk_main_quit), NULL);
gtk_window_set_title(GTK_WINDOW(window), "GTK+ with VS2010");
gtk_widget_show(window);
gtk_main();
return 0;
}
Everything should now be ready to compile, link and run. If all went well, you should be greeted by the following:
Well that was fun, right? :)
If you're building GTK+ stack on Windows with the help of a guide like this, then the luxuries of using a precompiled binary will not be at your disposal.
In this case I would suggest the following approach.
Download the precompiled binaries - This has two advantages.
This ships with the pkg-config.exe utility which you could use for the compiled source.
This also contains the pkgconfig folder with a wealth of .pc files which can be adapted for the compiled source.
Compile the packages in the debug/release mode - well this is the main advantage of compiling it yourself - and systematically arrange the headers, libs and dlls/exe in include, lib and bin folder respectively.
Copy the pkgconfig folder from the precompiled_gtk_source\bin to compiler_gtk_source\bin and set the path of the PKG_CONFIG_PATH variable
to add the compiler_gtk_source\bin\pkgconfig to it.
Now, considering the fact the names of the libraries produced on compiling gtk yourself and the corresponding library names in the precompiled package may be different, you might have to make the necessary changes in compiler_gtk_source\bin\pkgconfig*.pc files. I would go for a top-to-bottom approach here( We will see the advantages shortly). By top-to-bottom, I simply
mean that the end product will be the one to be edited first.
For example in this case the gtk+ is the end product and I will go for
configuring the .pc of this package first. The procedure is as follows:
First look at the name of the dll created. In my case it is gtk-3.0. If the .pc file that was shipped with the precompiled binaries have another name, then change the name appropriately - in my case it is gtk-3.0.pc. (This should be the case with all the other .pc files.)
Open the gtk-3.0.pc in a text editor and you will see stuff like below.
gtk-3.0.pc file:
prefix=c:/gtk_compilation/vs12/win32
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
targets=win32
Name: GTK+
Description: GTK+ Graphical UI Library
Version: 3.18.2
Requires: gdk-3.0 atk-1.0 cairo cairo-gobject gdk_pixbuf-2.0 gio-2.0
Requires.private: atk
Libs: -L${libdir} -lgtk-3
Cflags: -I${includedir}/gtk-3.0 -mms-bitfields
The one above is my customized file. If you don't know what each line does,
you could have a look at pkg-config help. The Require option,
however, needs a special mention. It is the place where you put the
dependancy dlls - again make sure that the name of the dlls exactly
matches what you have in your bin folder.
We need to recursively change the .pc files for the dlls which are included after the Require statement and if any .pcs are missing or if there is a name mismatch, you could make the appropriate changes. By now, you should already have understood the advantage of top-to-bottom approach. It helps us to sort out dependency .pc files systematically until we sort out all of them.
Now, run the below command to see if things are working.
Finally run the pkg-config command like below :
pkg-config --cflags gtk-3.0 --msvc-syntax > compilerflags.txt
pkg-config --libs gtk+-2.0 --msvc-syntax > linkerflags.txt
I just redirected the results to a text file named compilerflags.txt & linkerflags.txt so that you could use them any time you want by cut,copy & paste. Ofcourse, you should retain only the compiler specific flags.
Hope this helps somebody, sometime.
Give a look at this GTK+ with Visual Studio 2008 tutorial.
I would like to create a python C extension using XCode 4.5.2 so that I can use the xcode debugger. The extensions require the C file to be linked as a .so file. I have not been able to make .so file in xcode, only dylib files.
I tried as follows:
1. Used the C/C++ Library template, specified dynamic library
2. Change the Mach-O type to Bundle
3. Still could not make an .so so I changed the wrapper extension to .so, with no luck.
The post link below seems to say that I can just manually change the extension. This did not work for me, but I could have made another mistake.
how to make python load dylib on osx
Any thoughts on my problem?
.so files serve the same purpose on Linux (and some other Unixes) that .dylib files on OS X - they're dynamically linked libraries. If everything else fails, and Python cannot recognize your platform (and the fact that on OS X, it should look for .dylib files instead), make a symbolic link from the .dylib file with the same name but with the extension .so.
(Yes, this is a quite ugly hack, but it's simple, straightforward and it works.)