I am the current maintainer of GRX, which home page is http://grx.gnu.de/
This is an old 2D graphics library written in C with pascal interface for GPC (which is the main reason I use / maintain it). Written initially for DOS/DJGPP, it has been extended to Windows (mingw), linux (console and X11), plus some more esoteric systems.
Now a new user Schindler Karl-Michael karl-michael.schindler@web.de succeeded in compiling / running the X11 version under Mac OS X, with a few modifications.
I try to include a macosx target in the GRX sources, but there are a few problems. The first is that I have no Mac computer, so that I have to rely to others to experiment !
Besides some obvious modifications of header files, I included a set of makefile.osx in the src, test, test/bgi, pascal and pascal/bgi subdirectories, and corrected the configure script accordingly. The makefile.osx are copies of makefile.x11 with only in principle minor modifications. The most obvious is the change of dynamic library compilation (the $(GRX20SHna) target in src/makefile.osx), which I have modified according to your rts/makefile patch to compile GPC.
It works, but it was necessary to include extra -I and -L parameters to find the headers and libraries for X11, and for auxiliary libraries png, jpeg, tiff if they are used (there are options in configure to do so). This is not necessary in linux (and other targets) if these libraries are correctly installed in system directories, /usr and the like. In principle Karl-Michael has first done it, before compiling grx.
Is there something esoteric in Mac OS X, like /sbin/ldconfig to register .so dynamic libraries in linux ?
If you want to experiment, you can download grx 2.4.9 from the home page mentioned above, and a macosx.diff in the "more things" sections found in this page (it contains in addition some sanitization of other makefiles, to enable easier comparison). With it grx compiles/runs without the auxiliary libraries, but I had to include an extra $(X11LIBS) in the $(GRX20SHna) dynamic lib target.
You can find our full discussion in the GRX list archive at http://www.g-n-u.de/pipermail/grx/
The last message contains proposals to add -I and -L parameters to find location of auxiliary headers and libraries. It works that way, but I do not understand the need for these extra parameters.
Regards
Maurice
Maurice Lombardi wrote:
Is there something esoteric in Mac OS X, like /sbin/ldconfig to register .so dynamic libraries in linux ?
No, but one issue is install names
(from the OS X ld man page http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/ld.1.html, man pages for OS X tools are here https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/manpages-mpindex.html
-install_name name
Sets an internal "install path" (LC_ID_DYLIB) in a dynamic library. Any clients linked against the library will record that path as the way dyld should locate this library. If this option is not specified, then the -o path will be used. This option is also called -dylib_install_name for compatibility.
In other words, when creating the library, you must know (and record in the lib itself) where it will be installed (e.g. in /usr/local/lib). otool -D displays the install name https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/otool.1.html. install_name_tool http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/install_name_tool.1.html
can change the install name of an existing dylib. The new name can not be longer than the old name, unless -headerpad_max_install_names was passed to ld when the dylib was built.
Note that an install name can be relative to an executable, e.g. "@executable_path/../lib/libXXX.dylib" when the executable is an application package.
You can find our full discussion in the GRX list archive at http://www.g-n-u.de/pipermail/grx/
./configure --target=osx
Is there a reason using --target=osx, rather than e.g. --target=i686-apple-darwin ? I assume the --target line is needed for a cross build only, because config can "guess" it ?
There is a tool named lipo https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/lipo.1.html that combines multiple architectures into one binary. Apple gcc https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/gcc.1.html has this ability built-in
-arch arch Compile for the specified target architecture arch. The allowable values are i386, x86_64, ppc and ppc64. Multiple options work, and direct the compiler to produce "universal" binaries including object code for each architecture specified with -arch. This option only works if assembler and libraries are available for each architecture specified. (APPLE ONLY)
+# the apple linker ld has no option -s
The option was removed, but there are other options, see http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/ld.1.html and there is a separate strip tool https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/strip.1.html. However, one wouldn't want to remove all symbol info from a dynamic library, as at least the entry points must have their name saved. For a dynamic lib e.g. strip -x - r -u could be used.
Also, Apple ld can do smart linking, which dramatically reduces the size of binaries
-dead_strip Remove functions and data that are unreachable by the entry point or exported symbols.
The contents of a dynamic lib can be viewed with otool https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/otool.1.html or nm https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/nm.1.html
There is a separate tool dsymutil https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/dsymutil.1.html
to produce archived DWARF debug symbol files, separate from the .dylib.
These are a few points that came to my mind for Mac OS X.
Regards,
Adriaan van Os www.microbizz.nl
OK, now I understand some points with respect to dynamic libraries linking in Mac OS X
1) The only default directories are /usr/lib and /usr/local/lib, and there is nothing like /etc/ld.so.conf to register other default libraries. Your X11 libraries/header files being below the non standard /usr/X11 directory, it is mandatory to use -L parameters, i.e. $(X11LIBS) and -I parameters $(X11INCS) to locate them. This was provided in other makefiles, probably as a leftover of old times when both X11R5 and X11R6 systems coexisted. (In my linux systems, they are moved into standard locations below /usr, so that this is not really necessary).
2) due to two level namespaces, it is mandatory to give addons -lpng, etc when compiling the dynamic grx library, which is not necessary in linux which search/locate these libraries only at runtime, and do not need them at such compile time.
3) but I do not understand the need to give the location of these addon libraries with -L , and the location of their header files with -I : they are not in standard /usr/lib and /usr/include locations ? (or /usr/local..), at least symlinked from these standard locations (it seems usual practice to install them elsewhere, and to put symlinks to them in standard directories) ?
./configure --target=osx
Is there a reason using --target=osx, rather than e.g. --target=i686-apple-darwin ? I assume the --target line is needed for a cross build only, because config can "guess" it ?
GRX configure script is not made with standard GNU autotools. It was written by hand by Frank Heckenbach ih8mj@fjf.gnu.de, and I have only added some targets/options without changing the structure. Target names are short hands valids for native buildings. There is a possibility to use standard triplets, but they where intended for cross building from linux to DOS/Windows targets djgpp/mingw, for people which did not have full systems. I have modified configure to enable Mac OS X triplets, but probably this is not the good way to go. There is nothing like fat binaries in other systems. For double systems like 32bits / 64 bits, common nowadays, they are compiled separately and installed in different directories, and configure provides options to do this easily.
There is a tool named lipo https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/lipo.1.html that combines multiple architectures into one binary. Apple gcc https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/gcc.1.html has this ability built-in
-arch arch Compile for the specified target architecture arch. The allowable values are i386, x86_64, ppc and ppc64. Multiple options work, and direct the compiler to produce "universal" binaries including object code for each architecture specified with -arch. This option only works if assembler and libraries are available for each architecture specified. (APPLE ONLY)
We will have to think to that in a second step.
+# the apple linker ld has no option -s
The option was removed, but there are other options, see http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/ld.1.html and there is a separate strip tool https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/strip.1.html.
However, one wouldn't want to remove all symbol info from a dynamic library, as at least the entry points must have their name saved. For a dynamic lib e.g. strip -x - r -u could be used.
OK I have introduced that in osx makefiles
Also, Apple ld can do smart linking, which dramatically reduces the size of binaries
-dead_strip Remove functions and data that are unreachable by theentry point or exported symbols.
Same here
The modified macosx.diff has been uploaded to the "more things" section of grx.
Maurice
Maurice Lombardi wrote:
- but I do not understand the need to give the location of these addon
libraries with -L , and the location of their header files with -I : they are not in standard /usr/lib and /usr/include locations ? (or /usr/local..), at least symlinked from these standard locations (it seems usual practice to install them elsewhere, and to put symlinks to them in standard directories) ?
These addon libs are not installed by default on Mac OS X. They come with e.g. X11 and GTK+ and are usually not symlinked to the standard libs. That's just a different habit than on Linux. I guess that's because many Mac OS X software packages will use the system software instead. Of course, that makes such software more difficult to port.
As a side bar, I will note that software that uses X11, doesn't usually have the native Mac OS X look. GIMP for OSX http://gimp.lisanet.de for example no longer uses X11 as of version 2.8
Regards,
Adriaan van Os
Le 15/11/2012 10:05, Adriaan van Os a écrit :
Maurice Lombardi wrote:
- but I do not understand the need to give the location of these
addon libraries with -L , and the location of their header files with -I : they are not in standard /usr/lib and /usr/include locations ? (or /usr/local..), at least symlinked from these standard locations (it seems usual practice to install them elsewhere, and to put symlinks to them in standard directories) ?
These addon libs are not installed by default on Mac OS X. They come with e.g. X11 and GTK+ and are usually not symlinked to the standard libs. That's just a different habit than on Linux. I guess that's because many Mac OS X software packages will use the system software instead. Of course, that makes such software more difficult to port.
As a side bar, I will note that software that uses X11, doesn't usually have the native Mac OS X look. GIMP for OSX http://gimp.lisanet.de for example no longer uses X11 as of version 2.8
So, to be sure I understand: GIMP-2.6.12-SnowLeopard-Lion.dmg the last which uses X11, contains 2.hfs/GIMP 2.6.12 SnowLeopard Lion/Gimp.app/Contents/Resources/lib which contains the libjpeg.dylib libpng.dylib and libtiff.dylib we need as addons in grx. Where the content of this /lib will go when installed ? not to /usr/lib ? not even symlinked to there.
Specifically to Karl-Michael: where these addon libraries are actually in your system ? What are the symlinks ?
Maurice
Maurice Lombardi wrote:
Le 15/11/2012 10:05, Adriaan van Os a écrit :
Maurice Lombardi wrote:
So, to be sure I understand: GIMP-2.6.12-SnowLeopard-Lion.dmg the last which uses X11, contains 2.hfs/GIMP 2.6.12 SnowLeopard Lion/Gimp.app/Contents/Resources/lib which contains the libjpeg.dylib libpng.dylib and libtiff.dylib we need as addons in grx. Where the content of this /lib will go when installed ? not to /usr/lib ? not even symlinked to there.
On Mac OS X, a .app folder is an application package. So, what you are seeing here is not an install package, but the contents of a ready-to-run application with private .dylibs that are not shared with other applications.
Regards,
Adriaan van Os
Le 15/11/2012 22:02, Adriaan van Os a écrit :
Maurice Lombardi wrote:
Le 15/11/2012 10:05, Adriaan van Os a écrit :
Maurice Lombardi wrote:
So, to be sure I understand: GIMP-2.6.12-SnowLeopard-Lion.dmg the last which uses X11, contains 2.hfs/GIMP 2.6.12 SnowLeopard Lion/Gimp.app/Contents/Resources/lib which contains the libjpeg.dylib libpng.dylib and libtiff.dylib we need as addons in grx. Where the content of this /lib will go when installed ? not to /usr/lib ? not even symlinked to there.
On Mac OS X, a .app folder is an application package. So, what you are seeing here is not an install package, but the contents of a ready-to-run application with private .dylibs that are not shared with other applications.
So, if several applications, say GRX and GIMP, use the same addons dylibs, there are several copies of the same on the disk, and also in memory if they are run simultaneously. This is really not economical. May be Apple thinks that nowadays all kind of memories are cheap and abundant. So why spare some ? Anyway this is a sure way to avoid version conflicts.
Maurice
-
Adriaan van Os -
Maurice Lombardi