I tried it with 8.10, and as predicted those are not the only two problems there. I had to make numerous changes to the FDO source code to make it compile (mostly having to do with string.h and memory.h having to be explicitly included, and also a lot of constant strings being declared as char* instead of const char* in FDO). The third party components also fail, starting with Apache, but what I did there was to simply rm -rf the whole /Thirdparty/apache directory, thus forcing the build to use Ubuntu's built-in stuff, which is already compiled. I can probably make some patches for FDO itself, but I won't bother with the Thirdparty stuff (it's not my problem to maintain Apache, Apache already maintains Apache). As it is, the code is not even close to compiling on Ubuntu (which is now the most popular distro out there).
> -----Original Message-----
> From:
[hidden email] [mailto:fdo-internals-
>
[hidden email]] On Behalf Of Traian Stanev
> Sent: Friday, November 28, 2008 12:06 PM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] FDO Open Source 3.3.2 RC2
>
>
> Hi Frank,
>
> I can verify the Ubuntu x64 FDO build in a few days as an extra data
> point. However, I have the latest Ubuntu (8.10) so who knows what other
> problems I'll hit -- generally when I compile on Ubuntu I do it against
> the system packages (I delete things from /Thirdparty to avoid all the
> Thirdparty problems).
>
> Traian
>
>
> > -----Original Message-----
> > From:
[hidden email] [mailto:fdo-internals-
> >
[hidden email]] On Behalf Of Frank Warmerdam (External)
> > Sent: Friday, November 28, 2008 11:59 AM
> > To: FDO Internals Mail List
> > Subject: Re: [fdo-internals] FDO Open Source 3.3.2 RC2
> >
> > Helio Chissini de Castro wrote:
> > > On Quinta 27 Novembro 2008, Greg Boone wrote:
> > >> Hi Frank,
> > >>
> > >> Can you make the required changes and submit the fixes? I don't
> have
> > a 64
> > >> bit Linux environment available for testing at the moment.
> > >>
> > >
> > > I have plenty at lab.
> > > Need a testcase only.
> > >
> > > The second bug is obvious in case of linux x86_64
> >
> > Helio / Greg,
> >
> > I have included a fix in the ticket (#423), and I am willing to apply
> > it in
> > trunk if no one sees a problem with it. I'd prefer to be able to
> test
> > it
> > in a running system if I could.
> >
> > > The first one is easy to solve with cmake than auto*tools ( i
> solved
> > long time
> > > ago in cmake build )
> >
> > I'm afraid I don't understand your point. The problem is related to
> > the
> > boost build system which does not use autotools as far as I recall
> (it
> > uses
> > jam). The build is launched from Thirdparty.sh but this is not
> > particular
> > to automake, etc. Can you suggest a chance in Thirdparty.sh that
> will
> > make
> > this work? If so, please note it in the ticket, and I'll test it out
> > and
> > commit.
> >
> > It almost sounds like you are suggesting replacing the boost build
> > system
> > with cmake. Surely we aren't contemplating replacing the internal
> > build
> > system for all the third party packages!
> >
> > Best regards,
> > --
> > ---------------------------------------+-----------------------------
> --
> > -------
> > I set the clouds in motion - turn up | Frank Warmerdam,
> >
[hidden email]
> > light and sound - activate the windows |
http://pobox.com/~warmerdam> > and watch the world go round - Rush | Geospatial Programmer for
> Rent
> >
> > _______________________________________________
> > fdo-internals mailing list
> >
[hidden email]
> >
http://lists.osgeo.org/mailman/listinfo/fdo-internals> _______________________________________________
> fdo-internals mailing list
>
[hidden email]
>
http://lists.osgeo.org/mailman/listinfo/fdo-internals
