[rrd-developers] Compiling 1.2.14 for OSX 10.4.x

D.Walsh info at daleenterprise.com
Thu Oct 12 11:41:45 MEST 2006

Hash: SHA1

Sorry I didn't get back to you sooner Tobias with the build details  
you asked for, still hard-coding compiler flags I see.

Building on intel Mac's with the mainstream source seems to be an  
issue for many people because it's not so straight forward

Three things, (see end)
- --shared (in bindings/puthon) doesn't work in OSX.

Depending on the intended results you have the following options

- -bundle (see bundle_loader)

This option is passed to the linker and can be used together with the  
- -bundle_loader option when creating a bundle.
It specifies the name of a bundle loader program that will load the  
bundle file being created and linked.
Undefined symbols in the bundle file are resolved against the bundle  
loader program.

gcc -bundle -o my_module.so my_module.c
gcc -bundle -bundle_loader /usr/local/bin/my_app.bin  -o my_module.so  

- -dynamic

This option is passed to the linker and requires no additional  
This option is almost a drop in replacement for the -shared linker  
flag and in rare instances where it does not result in a working.

gcc -dynamic -o my_module.so my_module.c (this might be what you want)
gcc -module -dynamic -o my_module.so my_module.c (this is probably  
what you want)

Over time I've compiled some OSX specific building information,  
here's some you may find useful.

This file does not exist on Mac OS X, but the functionality does  
exist. You can simple include stdlib.h or create own version of the  
file using the following code.
#ifndef _ALLOCA_H

#undef  __alloca

/* Now define the internal interfaces.  */
extern void *__alloca (size_t __size);

#ifdef  __GNUC__
# define __alloca(size) __builtin_alloca (size)
#endif /* GCC.  */


The API ftw traverses through the directory hierarchy and calls a  
function to get information about each file.
In Mac OS X, use the API fts_open to get a handle on the file  
hierarchy, use fts_read to get information on each file, and use  
fts_children to get a link to a list of structures containing  
information about files in a directory.

Instead Mac OS X uses fts which is very similar to ftw.h. However,  
there isn't a function similar to ftw in fts.h.
You must use fts_open,fts_children, and fts_close to implement file  
traverse. For example, in order to get a description of each file  
located in /usr/include using fts.h, then the code would be as follow:
/* assume that the path "/usr/include" has been passed through argv*/

fileStruct = fts_open(&argv, FTS_COMFOLLOW, 0);
dirList = fts_children(fileStruct, FTS_NAMEONLY);

fileInfo = fts_read(dirList->fts_pointer);

/* at this point, you would be able to extract information from the
FTSENT returned by fts_read */

fileStruct = fts_open(dirList->fts_link->fts_name,
FTS_PHYSICAL, (void *)result);

}while (dirList->fts_link != NULL);

ftsResult = fts_close(fileStruct);
See manual page for fts to understand the structures FTSENT, FTS and  
to understand the macros used in the code.
The sample code above shows a very simplistic file traversing.
  FFor instance, it is not considering possible subdirectories  
existing in the directory being searched.

Not supoorted, use unistd.h

Not supported, use unistd.h

malloc.h (was malloc/malloc.h)
Not supported, use stdlib.h

This header is supported in Linux for memory mapping, but not  
supported in Max OS X. In Mac OS X, you can use mmap for mapping  
files into memory.
If you wish to map devices, use IOKit.

Use NSModule as the interface for working with modules and symbols.  
NSModule is simply a void * defined in the <mach-o/dyld.h> header file.
Use the API: NSLinkModule.

For information on how to implement message queues, see the Apple  
Technical Note 1071.
The APIs implemented in msg.h are also not supported, such as msgget,  
msgsnd, msgrcv, and msgctl. the Apple Technical Note mentioned above  
will help you implement the functionality from these functions.

Use CoreFoundation localized string to access API.

This header file exists in Linux, but it doesn't in Mac OS X.  
However, pty is supported in Mac OS X.
The implementation process is done very differently from Linux. See  
the full description of the pty implementation in manual page for pty.

This header file is not present on the system. For file streaming use  

Not supported.

Mac OS X does not support this header file. You can use the header  
file swap.h to implement swap functionalities.
The swap.h header file contains a large number of APIs that can be  
used for swap-tuning control.

This header file has become obsolete, and has been replaced by  
termios.h, which is part of the POSIX standard.
These two header files are very similar, however, the termios.h does  
not include the same header files as termio.h.
Thus, you should make sure to look directly at the termios.h to make  
sure it does what your application needs.

Not supported, use utmp.h instead.

Not supported, use limits.h

Not supported, use CoreFoundation localized string API.

Not supported on Mac OS X.


Second: (library related)
It's not picking up the python library (I'm sure you can figure this  
one out like add it to the Makefile.am file and regenerate).


When building on OSX

Recommend that Apple's X11 be installed.

Recommend that libart-2.0 (--disable-shared) and libpng (--disable- 
static) be installed with a prefix of /usr/local

I'm gonna cheat a little now because I'm too lazy to actually edit  
the files properly and I want to build and report as I go.

# Fix the source to use -dynamic for python (the dirty sed trick).
mv bindings/python/Makefile.in bindings/python/Makefile.in.old && \
sed -e 's!^\(.*\)\(-module\).*!\1\2 -dynamic!' bindings/python/ 
Makefile.in.old >bindings/python/Makefile.in
rm -f bindings/python/Makefile.in.old

# in 10.3.x perl is 5.8.1, in 10.4.x perl is 5.8.6 and of course you  
can dynamically
# extract the information from perl (I just tested this example and  
it builds properly)
./configure \
- --prefix=/usr/local/rrdtool-1.2.14 \
- --enable-perl-site-install \
- --with-perl-options="INSTALLDIRS=site INSTALLSITEARCH=$(perl -MConfig  
- -e 'print "$Config{installarchlib}"') INSTALLSITELIB=$(perl -MConfig - 
e 'print "$Config{installprivlib}"')" \
LDFLAGS="-L/usr/X11R6/lib -L/usr/local/lib" \
CPPFLAGS="-D_THREAD_SAFE -I/usr/X11R6/include/freetype2 -I/usr/local/ 
include/libart-2.0 -I/usr/local/include/libpng -I/usr/local/include" \
LIBS="-lart_lgpl_2 -lpng -lz -lfreetype"

# Now fix the source to add libpython (the dirty sed trick).
mv bindings/python/Makefile bindings/python/Makefile.tmp && \
sed -e 's!^\(LIBS = -l\)\(.*\)!\1python -l\2!' bindings/python/ 
Makefile.tmp >bindings/python/Makefile
rm -f bindings/python/Makefile.tmp

After building, I checked it and it seemed to work properly, of  
course I use Apple's supplied libPng from the Application Services  
framework just to be different so I utilize the Apple provided  
dependancies software however I've generated a build using the  
mainstream 3rd party (unmodified) sources for libart and libpng and  
have put together an installer package to make everyone's life easier.

daleenterprise:/SourceCache/rrdtool-1.2.14 root# otool -L /usr/local// 
rrdtool-1.2.14; # Apple's ldd equivalent.
         /usr/local/rrdtool-1.2.14/lib/librrd.2.dylib (compatibility  
version 3.0.0, current version 3.8.0)
         /usr/X11R6/lib/libfreetype.6.dylib (compatibility version  
6.3.0, current version 6.3.0)
libPng.dylib (compatibility version 1.0.0, current version 1.0.0)
         /usr/lib/libz.1.dylib (compatibility version 1.0.0, current  
version 1.2.3)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 88.1.7)
daleenterprise:/SourceCache/rrdtool-1.2.14 root#

I've generated an installer package for (Universal Binary) Intel/PPC  
Mac's running 10.4.x so in case you want to grab it and distribute  
I'll leave it online for a day or two.

Since I kinda like the built-in fonts in 1.0.49 and it more than  
satisfies any of my personal needs. (I could never get 1.2.x to  
generate a graph that looked as good) plus I still have issues in my  
displayed time period that carries over to the 1.2.x versions that I  
just can't seem to resolve (I gave up thinking I was too dumb to  
figure it out) so playing with the PHP code to resolve the time  
display issue keeps getting put off in the hopes that some PHP guru  
figures it out for me (of course it could also be in my perl script  
that parses the log file.


Version: GnuPG v1.4.2.2 (Darwin)


Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://lists.ee.ethz.ch/rrd-developers
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi

More information about the rrd-developers mailing list