Re: [lcd4linux] Compiling on Mac OS X Snow Leopard

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Mattia, you're a star! Thank you so much for your efforts. I'm a little consumed with life ATM, but as soon as I have an opportunity I'll give it a go and report back. Thank you once again, Alexander
 > Date: Tue, 27 Dec 2011 15:54:04 +0100
> Subject: Re: [lcd4linux] Compiling on Mac OS X Snow Leopard
> From: mat...@gm...
> To: mi...@re...
> CC: atv...@ho...; lcd...@li...
> 
> just forgot to mention the operation sequence
> 
> 1) check out the svn trunk
> 2) apply the patch
> 3) recreate the configure script by running the bootstrap script
> 4) run the configure script
> 
> On Tue, Dec 27, 2011 at 3:40 PM, Mattia Jona-Lasinio
> <mat...@gm...> wrote:
> > Hi Michael and Alexander,
> >
> > during these holidays I had some spare time to spend on lcd4linux and
> > the mac os x support. I realized that some basic support was
> > already implemented in plugin_proc_stat and plugin_netinfo but I could
> > not make the netinfo part work on my system. I implemented the
> > plugin_meminfo and added the relevant ifdefs to detect the mac os x
> > environment. The diskstats and netdev plugin are still to be
> > implemented.
> >
> > The support is still at a very early stage and I only tested the X11
> > driver, that works with no problems.
> >
> > These are my notes to compile successfully.
> >
> > 1) You need to install on mac os x the full GNU autoconf, automake,
> > etc etc... tools
> > 2) You need to install the GNU libtool. The libtool version provided
> > with mac os x has a different syntax and does not work. Keep in mind
> > that the macport libtool will be installed as glibtool to avoid name
> > clashes so you need to force your system to use the GNU libtool
> > instead of the mac os x one. A symbolic link will do the job.
> > 3) The libiconv from the macport project misses the iconv_open,
> > iconv_close, iconv_..... functions. I don't know whether it is a bug
> > or not but the mac os x iconv library has those functions so I just
> > linked by hand against this library and everything went fine. Can
> > someone report on this?
> >
> > Happy holidays!
> >
> > Mattia
> >
> >
> >
> > On Thu, Dec 22, 2011 at 3:28 AM, Michael Reinelt <mi...@re...> wrote:
> >> Hi Mattia,
> >>
> >> looks fine, so go ahead!
> >>
> >>
> >> thanks a lot, Michael
> >>
> >>
> >> Am 2011-12-21 14:03, schrieb Mattia Jona-Lasinio:
> >>
> >>> Hi Michael,
> >>>
> >>> this is my patch to solve all the header related issues. If you agree
> >>> I will commit these changes right away.
> >>>
> >>> Best,
> >>>
> >>> Mattia
> >>>
> >>>
> >>> On Wed, Dec 21, 2011 at 12:20 PM, Mattia Jona-Lasinio
> >>> <mat...@gm...>  wrote:
> >>>>
> >>>> Hello Michael,
> >>>>
> >>>> On Wed, Dec 21, 2011 at 9:12 AM, Michael Reinelt<mi...@re...>
> >>>>  wrote:
> >>>>>
> >>>>> Hello Mattia,
> >>>>>
> >>>>>
> >>>>>> I managed to turn lcd4linux into lcd4mac ;) on an old mac powerbook G4
> >>>>>> with powerPC processor and OS X 10.5.8 (the latest supported OS X
> >>>>>> release for this processor architecture).
> >>>>>
> >>>>>
> >>>>>
> >>>>> Cool!
> >>>>>
> >>>>>
> >>>>>> I compiled the X11 driver only but I included all the plugins
> >>>>>> excluding the following:
> >>>>>>
> >>>>>> huawei: the flag IUCLC is used in one of the functions and it is
> >>>>>> absent in the OS X termios flags
> >>>>>
> >>>>>
> >>>>>
> >>>>> I have no idea about this plugin (I don't use it)
> >>>>
> >>>>
> >>>> Yep, me neither. I have no idea about the huawei stuff.
> >>>>
> >>>>
> >>>>>> i2c_sensors: PATH_MAX is defined in sys/syslimits.h; by including this
> >>>>>> header everything is fine
> >>>>>
> >>>>>
> >>>>> could this be fine on linux, too? in this case we could fix it globally.
> >>>>> Could you provide a patch?
> >>>>
> >>>>
> >>>> sure! On Linux we have PATH_MAX defined in linux/limits.h but we don't
> >>>> include it directly as it is automatically included by other headers.
> >>>>
> >>>>>
> >>>>>
> >>>>>> proc_stat: OS_X doesn't have a proc filesystem so this plugin does not
> >>>>>> apply
> >>>>>
> >>>>>
> >>>>> Is there a (simnple) way to exclude this plugin on mac somehow in the
> >>>>> autoconf toolchain?
> >>>>
> >>>>
> >>>> yes, I'm not very familiar with all the autoconf stuff but it should
> >>>> be feasible.
> >>>> A more important question is how do we gather system information on OS X
> >>>> if we don't have a proc filesystem to parse?
> >>>>
> >>>>
> >>>>>> The libtool works a bit differently so you will have to link by hand.
> >>>>>> Also depending on your installation the libiconv may differ. You may
> >>>>>> want to specify the library full path when linking.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Well, that does not sound too good to me... I always thought that's why
> >>>>> we
> >>>>> use all this autoconf stuff?
> >>>>
> >>>>
> >>>> I just linked to check if the binary ran or not. It is surely possible
> >>>> to make it work with the libtool chain.
> >>>>
> >>>>>> I also spotted an error in timer.h This header must include the system
> >>>>>> header time.h or the struct timespec is undefined.
> >>>>>> Presently time.h is included in timer.c.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Again, if this change is fine for linux, too, I want to apply it
> >>>>> globally.
> >>>>
> >>>>
> >>>> This has nothing to do with OS X. It's a real programming error.
> >>>> Headers must be self contained and should compile also on their own.
> >>>> Presently timer.h compiles with a BIG warning concerning the undefined
> >>>> struct timespec. With the inclusion of time.h everything is fine.
> >>>>
> >>>>>
> >>>>>
> >>>>> merry christmas to everyone!
> >>>>>
> >>>>
> >>>> merry christmas to you all!
> >>>>
> >>>>>
> >>>>>
> >>>>> regards, michael
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Michael Reinelt<mi...@re...>
> >>>>> http://home.pages.at/reinelt
> >>>>> GPG-Key 0xDF13BA50
> >>>>> ICQ #288386781
> >>
> >>
> >> --
> >> Michael Reinelt <mi...@re...>
> >> http://home.pages.at/reinelt
> >> GPG-Key 0xDF13BA50
> >> ICQ #288386781