I just went on the xcb download page and downloaded the different archives (the most recent ones) but had no luck finding the implementation of xcb_map_window with grep. I've merely found its prototype though.
Since it has the xcb prefix, I thought it would be there.
What is the catch? Where is it?
Related
This is the problem:
(On Linux Slackware64) I compiled Inkscape (0.92.3) and found that exporting to PNG doesn't work. An indication on the terminal tells me:
libpng warning: Application built with libpng-1.6.16 but running with 1.5.13
First reaction was to list the linked libraries using ldd. Indeed, both libpng-1.6.16 and libpng-1.5.13 are listed as necessary.
So, I suspected that some of the other libraries was requiring libpng-1.5.13. I made a small Python program which takes all the libraries (except the libpngs) and applies ldd to each of them. None of them listed libpng15. What now? I suspect that if any of the secondary libraries needed libpng15, it would be listed here, but, just in case I made the search recursive. No luck.
So it was, apparently, inkscape itself requesting the old version. A simple search in all files in the search tree only showed the string 'png15' in the viewer and actual inkscape executable.
There are probably older programs of mine still linked with png15, so I probably want to keep that version around.
Most, if not all references on the net mentioning this error (or similar) refer to programs with very old pnglibs (1.2.4x) trying to use a newer version, but here it's the other way around.
libpng-config --version reports 1.6.16
Any suggestion how to identify the source of this problem? Particularly why inkscape included the old libpng?
I would like to deploy a .dylib on OSX, which has been created with Delphi. This .dylib should be loadable by third-party applications.
This is going to seem like a duplicate question, but after plenty of searching, I can't find an answer for it. It's the same issue as this: https://forums.embarcadero.com/thread.jspa?messageID=592417
The problem is that the .dylib requires libcgunwind.1.0.dylib, but that it cannot find it when being run from a third-party application. As a test, I tried copying libcgunwind.1.0.dylib into usr/lib, and that worked. When OSX cannot locate the .dylib, it will always search in usr/lib. Unfortunately, I do not want to do this as a final solution, because it would require elevated permissions, and seems like a heavy handed way of dealing with a simple problem.
Inspecting a bit closer, I used otool to inspect my .dylib, and it gave me the following path: #rpath/libcgunwind.1.0.dylib.
The trouble is, there's no accounting for what paths will be listed in #rpath, when your .dylib is being run by a third-party application. For this to work, the application would always have to provide an absolute path to libcgunwind.1.0.dylib.
The obvious solution is to use install_name_tool to replace #rpath with #loader_path. If my logic is correct, this should cause my .dylib to always find libcgunwind.1.0.dylib, as long as they are in the same folder. This makes sense, as the .dylib ought to be in charge of finding its own dependencies.
So, I tried the following command line:
install_name_tool -change #rpath/libcgunwind.1.0.dylib #loader_path/libcgunwind.1.0.dylib libTest.dylib
and received this message:
install_name_tool: file not in an order that can be processed (local relocation entries out of place): libTest.dylib
I did some searching around for this error message, and I haven't been able to find any information on it. I have to assume that install_name_tool is expecting some specific conventions found in a gcc or llvm built .dylib, and that Delphi's compiler is not providing those conventions.
I did some digging around in Delphi's compiler dccosx, and checked the command-line arguments Delphi is sending to it, but I can't find any useful options. This way of using libcgunwind.1.0.dylib, seems to be implicit to the compiler, and not something I can adjust.
I'm not suggesting that this is the right way to tackle the issue, these are just the latest things that I've tried. If you can come up with a different way of working around the problem, please share your ideas!
The install_name_tool seems to require that certain parts of the dylib are in a certain order like "local relocation entries" then "symbol table", "local symbols", ... The error message means that this order is not as expected.
My suggestion is that you try to patch the dylib file. I do that all the time with OSX executables because I need to tell them which dylib versions they are compatible with. This fixes a couple of bugs in a Delphi OSX application. A dylib has a very similar structure as the executable. My experience is that patching these files is not as complicated as it sounds.
You can find the description of the file structure here:
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html
The LC_LOAD_DYLIB section is what you'll need to look at. You should be able to replace the dylib names with something longer as this section usually has some extra padding.
I'm trying to build apple's opensource libc (from http://www.opensource.apple.com/source/Libc/Libc-763.11/) on my OS X 10.6.8 laptop. This is in an attempt to essentially get a locally generated replica of /usr/lib/libSystem.B.dylib, which I intend to experiment on further.
I see a couple basic roadblocks though (unless, obviously, I'm missing something basic):
No instructions on how to do the build. There are a couple of Makefiles in the URL I reference above, but they fail to build when I try to do straightforward makes:
$make -f Makefile
Makefile:14: *** missing separator. Stop.
I suspect the source available for download is incomplete. Not incomplete in the sense that Apple isn't revealing all of the changes, but incomplete in the sense that there are source files that were (presumably) not modified by Apple, so isn't included in the collection. For example, I don't see the implementation of the "open" call (which, in the gnu libc hierarchy, is available at io/open.c)
The closest reference I could find after some googling was this: http://www.projectosx.com/forum/index.php?showtopic=1922&st=0&p=12457&#entry12457 but it still isn't close enough for my taste!
Any pointers?
Thanks!
Only some general pointers (although some links are discussing older OSX versions):
http://darwinbuild.macosforge.org/trac/ticket/6
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-projects/darwin/overlay/sys-libs/libc-darwin/libc-darwin-391.ebuild?view=markup&sortby=log
http://althenia.net/wiki/darwin#standard_library_libc
http://dev.gentoo.org/~vapier/CROSS-COMPILE-GUTS
http://www.raccoonfink.com/fink/darwin-cross/
I am building a win32 executable. The compiler is the latest version of MinGW. The library dependencies are GLUT and libpng.
I first tested on a windows 7 machine, and had to obtain libpng3.dll and freeglut32.dll. However, on XP, I had to (in addition) acquire zlib1.dll.
The XP machine was a VM with a fresh install, so I suspect a fresh win7 machine may also be lacking zlib1.
My question is how do I go about finding out which dll's I need to distribute? How do I know, a priori, which dynamic libraries are needed for my program to run on a particular system? I suppose this is what installer programs are for... I'm guessing that what the installer does is look through the system to find out which dependencies are unsatisfied, and then provides them. So this way if I were to distribute my program I could check if the user's machine already has zlib1.dll, and I won't install zlib1.dll if it's already found in the system directory. However I never found a document that said to me specifically, "libpng requires zlib", and so, until such point as I tested the executable on a machine lacking zlib, I was unaware of this dependency. How can I create my dependency list without having a fresh install of each version of every operating system to test on?
One idea I have is to decompile the executable, or through some method examine the linking process, to find all the libraries that are being linked at runtime. The problem now becomes figuring out which of these are supposed to already be there, and which of them I could be expected to provide in the distribution.
edit: Okay, I looked, and the installation of libpng I downloaded did provide zlib1.dll inside its bin directory. So not including it is pretty much my fault. In any case, Daniel's answer is definitive.
Dependendy Walker shows all deps of your program.
The correct answer to this question, in my view, is to start at the source rather than to reverse engineer the solution with Dependency Walker, awesome and useful tool though it undoubtedly is.
The problem with Dependency Walker is that it only tells you what one particular run of the program requires on the OS on which you run it. If you have any dynamic loading dependencies in your app then you would only pick those up if you made sure you profiled the app with Dep. Walker and forced it through those dynamic loads.
My preferred approach to this problem is to start with your own source code and analyse and understand what it depends upon. It's often easy enough to do so because you know it well.
You need to understand what are the deployment requirements for your compiler. You usually have options of linking statically and dynamically to the C++ runtime. Obviously a dynamic link results in a deployment requirement.
You will also likely link to 3rd party code. One example would be Windows components. These typically don't need deployment, you can take them as already being in place. Sometimes that's not true, e.g. GDI+ on Windows 2000.
Sometimes you will link statically to 3rd party code (again easy), but if you link dynamically then that implies a deployment requirement.
This is the FindGTK.cmake:
# don't even bother under WIN32
IF(UNIX)
...
ENDIF(UNIX)
So it's not intended to work in windows at all,even though I've already installed the gtk+-bundle_2.20.0-20100406_win32 days ago.
How should I properly use gtk with cmake now?
Given that you are using GTK 2.20.0 (i.e. version is >= 2), you should be using GTK2 instead of GTK. But, if FindGTK2 has the same problem, then you can use find_path to locate the header files, and you can use find_library to locate the associated library files. Putting those together, you can construct the symbols GTK2_FOUND, GTK2_LIBRARIES, and GTK2_INCLUDE_DIRS that it should produce. You may find my FindUnitTestPlusPlus.cmake file a little bit helpful; it makes use of "FindPackageHandleStandardArgs", which takes care of the nitty gritty details of making sure to fail if the library isn't there and the REQUIRED flag is given. Unfortunately, there really isn't much documentation out there on creating custom FindXYZ.cmake modules; however, you should be able to hack something together from the existing modules, I think.
Another option is to contact the maintainer of that particular module. A list of CMake find module maintainers may be found at the link. Philip Lowman is the go-to guy for the FindGTK2 module.