Hi Maurice
>> There are the additional issues when enabling tiff, png and jpeg.
>> They are not readily available, but need to be installed in --prefix such as /usr/local, /opt or /sw
>> Therefore, the include and lib paths need to be passed to the compiler and the linker.
>
> In other systems, it is supposed that these softwares are first installed in a known system directory, i.e.
>
> /usr or /usr/local in linux
> c:\mingw in mingw
> c:\djgpp in djgpp
>
> In that case .h and library files are found by the system and your following changes are not needed to compile grx.
On Mac OS X, Apple's stuff is in /usr, which should be used by others. Therefore, most standalone installers of unixoid software install their stuff into /usr/local. Package managers (MacPorts, Fink, Homebrew, ...) use /opt, /sw, ....
Since there is no Apple version of libtiff, libjpeg in /usr, they must be installed by the user manually or using a package manager and it is at least tricky to know, where it is installed. gcc and ld usually have no clue about /usr/local, /opt, even if package managers are installed. In simple cases they use configure --prefix=...., which then results in passing CFLAGS=-I$PREFIX/include and LDFLAGS=-L$PREFIX/lib to gcc/ld.
> notice that $(includedir) is the path where .h files of grx are to be installed, not the one where other .h files are to be found (and similarly for libraries)
To the best of my knowladge, this is the default use of --prefix: install the new library and .h files exactly there, where to search for depending .h files and libraries. At least that is the policy of the package managers, i know. If a particular install directory is needed, an explicit INSTALLDIR is used.
> Doing your changes enables to compile and install grx, but you will not be able to use them in user's programs if you do not make them visible by the system. The usual way to do this is to install them in system directories like above.
I would assume that "make install" is exactly doing that?
> I had one case in which this way was not convenient, an old mingw
> snip
> This way all is available both when compiling grx and in user's programs
I do not think, we need all of this.
> Do you see an objection to follow this in Mac OS X. As I said you need
> something like this to compile user's programs.
In the end i would setup a package description for fink, which will make it easy for others to use grxlib in their program, but I have the impression, that we still talking about slightly different things. I attach the log of the build run, which fails because of -soname.
> I can include explanations in the readme files.
no need yet.
>> diff -r '-x*.*o' ../grx249 2/src/makefile.x11 ./src/makefile.x11
>>
>>> $(CC) $(LDOPT) -shared -lX11 -L/usr/X11/lib -o $(GRX20SHna) $(LO) $(LIBS)
>
> This is not the content of makefile.osx, with the .dylib stuff. Have you tried it ?
You are right. This part was from a previous try. I needed to apply the patch again to unmodified! sources. See the attached log files.
Michael.
