FDO 3.7 beta2 timeframe

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

FDO 3.7 beta2 timeframe

Trevor Wekel

Hello list,

 

Do we want do a beta2 for FDO which includes GDAL 1.9?  beta1 was created just before the GDAL upgrade.  I may be able to spend some time building the SDKs next week if needed.

 

Regards,

Trevor

 


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: FDO 3.7 beta2 timeframe

Trevor Wekel

Hi list,

 

Just pinging again.  Do we also want to take a run at a 64 bit Linux build on centos5 for beta2? 

 

Since beta1 was posted on December 2, 2011 the timing may be appropriate for beta2 and a ramp up to RC and Release. 

 

Regards,

Trevor

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: April 19, 2012 10:31 AM
To: FDO Internals Mail List
Subject: [fdo-internals] FDO 3.7 beta2 timeframe

 

Hello list,

 

Do we want do a beta2 for FDO which includes GDAL 1.9?  beta1 was created just before the GDAL upgrade.  I may be able to spend some time building the SDKs next week if needed.

 

Regards,

Trevor

 


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: FDO 3.7 beta2 timeframe

Greg Boone

We need to move to RC1. I don’t see the need for a Beta2.

 

Greg

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Monday, April 23, 2012 12:16 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: FDO 3.7 beta2 timeframe

 

Hi list,

 

Just pinging again.  Do we also want to take a run at a 64 bit Linux build on centos5 for beta2? 

 

Since beta1 was posted on December 2, 2011 the timing may be appropriate for beta2 and a ramp up to RC and Release. 

 

Regards,

Trevor

 

From: [hidden email] [hidden email] On Behalf Of Trevor Wekel
Sent: April 19, 2012 10:31 AM
To: FDO Internals Mail List
Subject: [fdo-internals] FDO 3.7 beta2 timeframe

 

Hello list,

 

Do we want do a beta2 for FDO which includes GDAL 1.9?  beta1 was created just before the GDAL upgrade.  I may be able to spend some time building the SDKs next week if needed.

 

Regards,

Trevor

 


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: FDO 3.7 beta2 timeframe

Trevor Wekel

Sounds good to me.  Did you want Jackie and I to start working on open source builds/SDKs?  I do not have licenses in place for ESRI but I recall that someone was able to build the ESRI-based providers from the SDK I created last time around.  Is that approach still acceptable?

 

Do we want to take a run at CentOS 5 64 bit for this release to see how close we are?

 

Also, are the official builds to be built with build_linux.sh and build_thirdparty.sh?  I believe Jackie was looking into the cmake process for Ubuntu.

 

Regards,

Trevor

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: April 24, 2012 9:11 AM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: FDO 3.7 beta2 timeframe

 

We need to move to RC1. I don’t see the need for a Beta2.

 

Greg

 

From: [hidden email] [[hidden email]] On Behalf Of Trevor Wekel
Sent: Monday, April 23, 2012 12:16 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: FDO 3.7 beta2 timeframe

 

Hi list,

 

Just pinging again.  Do we also want to take a run at a 64 bit Linux build on centos5 for beta2? 

 

Since beta1 was posted on December 2, 2011 the timing may be appropriate for beta2 and a ramp up to RC and Release. 

 

Regards,

Trevor

 

From: [hidden email] [hidden email] On Behalf Of Trevor Wekel
Sent: April 19, 2012 10:31 AM
To: FDO Internals Mail List
Subject: [fdo-internals] FDO 3.7 beta2 timeframe

 

Hello list,

 

Do we want do a beta2 for FDO which includes GDAL 1.9?  beta1 was created just before the GDAL upgrade.  I may be able to spend some time building the SDKs next week if needed.

 

Regards,

Trevor

 


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: FDO 3.7 beta2 timeframe

Greg Boone

If you both can look into the Linux SDKs I can take care of the windows side, as well as the source distributions. For Linux, a 64bit distribution would be a good idea. You can use either the .sh files or cmake for the build.

 

Greg

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Tuesday, April 24, 2012 11:53 AM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: FDO 3.7 beta2 timeframe

 

Sounds good to me.  Did you want Jackie and I to start working on open source builds/SDKs?  I do not have licenses in place for ESRI but I recall that someone was able to build the ESRI-based providers from the SDK I created last time around.  Is that approach still acceptable?

 

Do we want to take a run at CentOS 5 64 bit for this release to see how close we are?

 

Also, are the official builds to be built with build_linux.sh and build_thirdparty.sh?  I believe Jackie was looking into the cmake process for Ubuntu.

 

Regards,

Trevor

 

From: [hidden email] [hidden email] On Behalf Of Greg Boone
Sent: April 24, 2012 9:11 AM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: FDO 3.7 beta2 timeframe

 

We need to move to RC1. I don’t see the need for a Beta2.

 

Greg

 

From: [hidden email] [[hidden email]] On Behalf Of Trevor Wekel
Sent: Monday, April 23, 2012 12:16 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: FDO 3.7 beta2 timeframe

 

Hi list,

 

Just pinging again.  Do we also want to take a run at a 64 bit Linux build on centos5 for beta2? 

 

Since beta1 was posted on December 2, 2011 the timing may be appropriate for beta2 and a ramp up to RC and Release. 

 

Regards,

Trevor

 

From: [hidden email] [hidden email] On Behalf Of Trevor Wekel
Sent: April 19, 2012 10:31 AM
To: FDO Internals Mail List
Subject: [fdo-internals] FDO 3.7 beta2 timeframe

 

Hello list,

 

Do we want do a beta2 for FDO which includes GDAL 1.9?  beta1 was created just before the GDAL upgrade.  I may be able to spend some time building the SDKs next week if needed.

 

Regards,

Trevor

 


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: FDO 3.7 beta2 timeframe

Trevor Wekel

Ok.  Thanks Greg.  I will chat more with Jackie offline about the Linux builds.  The .sh file build should generate an FDO image with the same third party components as the Windows version.

 

The cmake build may generate a build which uses more of the distro’s third party components.  This may not be identical to the Windows image but could be more acceptable from a packaging perspective.  For example, building our own version of OpenSSL is considered a “no-no” from a packaging perspective.

 

Regards,

Trevor

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: April 24, 2012 9:57 AM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: FDO 3.7 beta2 timeframe

 

If you both can look into the Linux SDKs I can take care of the windows side, as well as the source distributions. For Linux, a 64bit distribution would be a good idea. You can use either the .sh files or cmake for the build.

 

Greg

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Tuesday, April 24, 2012 11:53 AM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: FDO 3.7 beta2 timeframe

 

Sounds good to me.  Did you want Jackie and I to start working on open source builds/SDKs?  I do not have licenses in place for ESRI but I recall that someone was able to build the ESRI-based providers from the SDK I created last time around.  Is that approach still acceptable?

 

Do we want to take a run at CentOS 5 64 bit for this release to see how close we are?

 

Also, are the official builds to be built with build_linux.sh and build_thirdparty.sh?  I believe Jackie was looking into the cmake process for Ubuntu.

 

Regards,

Trevor

 

From: [hidden email] [hidden email] On Behalf Of Greg Boone
Sent: April 24, 2012 9:11 AM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: FDO 3.7 beta2 timeframe

 

We need to move to RC1. I don’t see the need for a Beta2.

 

Greg

 

From: [hidden email] [[hidden email]] On Behalf Of Trevor Wekel
Sent: Monday, April 23, 2012 12:16 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: FDO 3.7 beta2 timeframe

 

Hi list,

 

Just pinging again.  Do we also want to take a run at a 64 bit Linux build on centos5 for beta2? 

 

Since beta1 was posted on December 2, 2011 the timing may be appropriate for beta2 and a ramp up to RC and Release. 

 

Regards,

Trevor

 

From: [hidden email] [hidden email] On Behalf Of Trevor Wekel
Sent: April 19, 2012 10:31 AM
To: FDO Internals Mail List
Subject: [fdo-internals] FDO 3.7 beta2 timeframe

 

Hello list,

 

Do we want do a beta2 for FDO which includes GDAL 1.9?  beta1 was created just before the GDAL upgrade.  I may be able to spend some time building the SDKs next week if needed.

 

Regards,

Trevor

 


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: FDO 3.7 beta2 timeframe

Jackie Ng
Just a thing about the cmake builds.

I have a pending patch to submit for review which will allow everything sans the King Oracle and ArcSDE providers to be built via CMake. King Oracle has no CMakeLists.txt files and ArcSDE I don't have the required SDKs to build and verify.

However, here's the kicker: the resulting binaries built via CMake are still not usable for building mapguide on linux because:

 a) The CMake build produces binaries with different so names (eg. libFDO.so.3.7.0 instead of libFDO-3.7.0.so)
 b) Doing symlink tricks (eg. Symlink libFDO-3.7.0.so to libFDO.so.3.7.0) doesn't work either as MapGuide will crash out trying to load these symlinked so files, though this may not even be a working solution (noob-ism showing here)

Still, I'd still like get these patches in for 3.7 anyway as it contains some more build fixes for ubuntu. Being able to natively build 3.7 on ubuntu is still something nice to have.

So for 3.7, looks like the official build will still have to be automake-based

- Jackie
Reply | Threaded
Open this post in threaded view
|

Re: FDO 3.7 beta2 timeframe

Johan Van de Wauw
On Fri, Jun 8, 2012 at 3:05 PM, Jackie Ng <[hidden email]> wrote:
> Just a thing about the cmake builds.

>
>  a) The CMake build produces binaries with different so names (eg.
> libFDO.so.3.7.0 instead of libFDO-3.7.0.so)
>  b) Doing symlink tricks (eg. Symlink libFDO-3.7.0.so to libFDO.so.3.7.0)
> doesn't work either as MapGuide will crash out trying to load these
> symlinked so files, though this may not even be a working solution (noob-ism
> showing here)

Just using symlinks will also cause problems outside mapguide. The
sonumber is part of the soname is part of a library, and it is the
name in the library that the linker will record. See eg objdump -p
libFDO-3.7.0.so
In the dynamic section you will find "  SONAME               libFDO.so.3"
This is what the linker will take when you link to that library (in
fact above this line you will see how libFDO links to other libs in
the same way). So that file should exist.

In fact what you want is not a library without a SOVERSION, but one
with a release number included in the library name. In
automake/libtool this is easy to accomplish using -release (
http://www.gnu.org/software/libtool/manual/html_node/Release-numbers.html#Release-numbers
).

AFAIK no such mechanism exists for cmake but it easy to do the same
thing, it requires 2 steps
1) remove the set_target_properties where the SOVERSION is set (it is
a bad SOVERSION anyway, soversions should be able to change
independently from version numbers)
2) replace the target_link_library name with one which includes the
version number, and change references accordingly.
An example patch is attached. similar patches are needed for every
library, and all libraries referencing FDO or other libraries should
be updated to FDO-${FDO_VERSION}.

Johan

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

fdocmake.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: FDO 3.7 beta2 timeframe

Greg Boone
 >> and all libraries referencing FDO or other libraries should be updated to FDO-${FDO_VERSION}.

Interesting ideas, but changing the resulting FDO library names for the 3.7 release is not very practical at this point in the cycle. If we do this, this should be done in the trunk, for the future 3.8 release.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Johan Van de Wauw
Sent: Friday, June 08, 2012 10:09 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] FDO 3.7 beta2 timeframe

On Fri, Jun 8, 2012 at 3:05 PM, Jackie Ng <[hidden email]> wrote:
> Just a thing about the cmake builds.

>
>  a) The CMake build produces binaries with different so names (eg.
> libFDO.so.3.7.0 instead of libFDO-3.7.0.so)
>  b) Doing symlink tricks (eg. Symlink libFDO-3.7.0.so to
> libFDO.so.3.7.0) doesn't work either as MapGuide will crash out trying
> to load these symlinked so files, though this may not even be a
> working solution (noob-ism showing here)

Just using symlinks will also cause problems outside mapguide. The sonumber is part of the soname is part of a library, and it is the name in the library that the linker will record. See eg objdump -p libFDO-3.7.0.so
In the dynamic section you will find "  SONAME               libFDO.so.3"
This is what the linker will take when you link to that library (in fact above this line you will see how libFDO links to other libs in the same way). So that file should exist.

In fact what you want is not a library without a SOVERSION, but one with a release number included in the library name. In automake/libtool this is easy to accomplish using -release ( http://www.gnu.org/software/libtool/manual/html_node/Release-numbers.html#Release-numbers
).

AFAIK no such mechanism exists for cmake but it easy to do the same thing, it requires 2 steps
1) remove the set_target_properties where the SOVERSION is set (it is a bad SOVERSION anyway, soversions should be able to change independently from version numbers)
2) replace the target_link_library name with one which includes the version number, and change references accordingly.
An example patch is attached. similar patches are needed for every library, and all libraries referencing FDO or other libraries should be updated to FDO-${FDO_VERSION}.

Johan
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

CMake build fixes (Re: FDO 3.7 beta2 timeframe)

Jackie Ng
In reply to this post by Johan Van de Wauw
Hi Johan,

Now that MapGuide 2.4 is out the door, I've had time to take another look at this.

My question is should this SONAME omission be done for all FDO shared libraries? Or just the "public" ones that would be linked by MapGuide (libFDO, libExpressionEngine)?

I also noticed that the file listing of a cmake build differs from an automake one. There are some libs that are being created as shared (dynamic) libraries instead of static ones. Doing a SHARED -> STATIC add_library replacement on the applicable CMakeLists.txt caused a whole load of linker errors. Obviously something extra needs to be done here.

For packaging purposes, the cmake build should be producing the same set of output files as the automake one.

Got any extra notes to share?

- Jackie
Reply | Threaded
Open this post in threaded view
|

Re: CMake build fixes (Re: FDO 3.7 beta2 timeframe)

Johan Van de Wauw
I'm extremely busy this week but I may have a look next week to the other issues you're talking about.

Anyway: since the autotools build is not using sonames anywhere it should be dropped here for every library. Better not to have a soname than one that is not correct or that is not used.
The version number of FDO should then be added to all public libraries; in the same way as it is done for the auto* build now. But you have to do this manually; AFAIK there is no switch in cmake that corresponds to libtool --release.

But before rushing to making these changes: what is the original reason that we have two build systems? We could also consider changing the autotools build to optionally use dynamic libraries...

Johan

On Mon, Oct 15, 2012 at 7:56 AM, Jackie Ng <[hidden email]> wrote:
Hi Johan,

Now that MapGuide 2.4 is out the door, I've had time to take another look at
this.

My question is should this SONAME omission be done for all FDO shared
libraries? Or just the "public" ones that would be linked by MapGuide
(libFDO, libExpressionEngine)?

I also noticed that the file listing of a cmake build differs from an
automake one. There are some libs that are being created as shared (dynamic)
libraries instead of static ones. Doing a SHARED -> STATIC add_library
replacement on the applicable CMakeLists.txt caused a whole load of linker
errors. Obviously something extra needs to be done here.

For packaging purposes, the cmake build should be producing the same set of
output files as the automake one.

Got any extra notes to share?

- Jackie



--
View this message in context: http://osgeo-org.1560.n6.nabble.com/FDO-3-7-beta2-timeframe-tp4898809p5008588.html
Sent from the FDO Internals mailing list archive at Nabble.com.
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: CMake build fixes (Re: FDO 3.7 beta2 timeframe)

Jackie Ng
The original build system was (and still is) automake.

CMake was introduced as an alternate build system (http://trac.osgeo.org/fdo/wiki/FDORfc21), but I guess nobody actually ever put out working binaries via CMake as all the official builds since its introduction were all still done through automake (I believe).

I only recently got CMake builds working in Ubuntu just in time for the MapGuide 2.4 release timeframe (The key was to always use internal GDAL/xalan/xerces, as Ubuntu hosted versions were too old or incompatible. Everything else worked with system-sourced libraries), but issues like this SONAME problem in particular prevented its use for the linux builds of MapGuide 2.4.

I like the CMake build system. It's much faster and you get nice build progress, but it still does not produce binaries that can be easily consumed by MapGuide, which is the ultimate deal-breaker.

- Jackie
Reply | Threaded
Open this post in threaded view
|

Re: CMake build fixes (Re: FDO 3.7 beta2 timeframe)

Johan Van de Wauw
Jackie,

I have some more time now.

Xalan and xerces do need a newer version indeed. I once packaged a version of xalan which should do the trick, when I was trying to get mapguide packaged for the osgeo livedvd. You can install it next to other versions in ubuntu. I rebuilt the package a few days ago [1].

For gdal the problem is that it relies also on xerces (optionally, it can also use expat): you can not link to two different versions of the same library (perhaps it is with some tricks, as was done for libtiff), so you can not use the debian/ubuntu version. 

The best solution would be that upstream (xalan/xerces) releases a version. Then that can be brought debian/ubuntu, so also gdal would use that. It seems they are finally working on a release (e.g. [2]). If we ever want fdo/mapguide in the official archives, this will probably have to happen first.

Anyway, I'm now preparing packages of fdo for ubuntu based on the cmake build. I'm using the current svn version for this. I'm also trying to set up a bazaar branch of the fdo code at launchpad. That will enable nightly builds for ubuntu of the current svn head if it manages to do the import (it failed last time I tried). 

Johan

[3] https://code.launchpad.net/osgeo-fdo

On Mon, Oct 15, 2012 at 11:06 AM, Jackie Ng <[hidden email]> wrote:
The original build system was (and still is) automake.

CMake was introduced as an alternate build system
(http://trac.osgeo.org/fdo/wiki/FDORfc21), but I guess nobody actually ever
put out working binaries via CMake as all the official builds since its
introduction were all still done through automake (I believe).

I only recently got CMake builds working in Ubuntu just in time for the
MapGuide 2.4 release timeframe (The key was to always use internal
GDAL/xalan/xerces, as Ubuntu hosted versions were too old or incompatible.
Everything else worked with system-sourced libraries), but issues like this
SONAME problem in particular prevented its use for the linux builds of
MapGuide 2.4.

I like the CMake build system. It's much faster and you get nice build
progress, but it still does not produce binaries that can be easily consumed
by MapGuide, which is the ultimate deal-breaker.

- Jackie



--
View this message in context: http://osgeo-org.1560.n6.nabble.com/FDO-3-7-beta2-timeframe-tp4898809p5008651.html
Sent from the FDO Internals mailing list archive at Nabble.com.
_______________________________________________
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