[mapguide-users] building 64bit openmapguide on rhel 5.4

Bracco Stefano Stefano.Bracco at eurac.edu
Fri Apr 16 02:38:12 EDT 2010


Sorry for late response, KFW is right, you can remove the IFDEF and you will be able to compile on RH 5.3, 5.4 and 5.5, but the IFDEF was added to implement that functionalities, so my advice is to consider to do something "alternative".

I don't know why, but the functionalities were implemented in the IFDEF in more recent releases of the DWF ToolKit (I suppose that Adobe decided to support 64 bit only in recent versions, so the ifdef in the preliminary releases was left intentionally blank, to prepare the code for new developments).

Here there is a license issue, because I'm not sure that can be used in production, anyway an alternative (and valuable) solution is to upgrade the version of the DWF ToolKit in the MapGuide (if I'm not wrong, the first version supporting 64x should be 7.3.x). You just need to untar the package in the right directory, the makefile/build file has minor changes and will work perfectly.
In this case you will see that the compilation will work successfully.

As it is recalled in many other parts, I suggest to do a make clean and recompile everything. There is no issue about compatibility with recent kernels and/or glibc libs, I also crosschecked this.

The advantage is that the code defined on that variables, is implemented in the newest version, and if you have any problem, at least you know that the toolkit is consistent.

Just my suggestion, let us know if you succeeded!

Stefano




-----Original Message-----
From: mapguide-users-bounces at lists.osgeo.org [mailto:mapguide-users-bounces at lists.osgeo.org] On Behalf Of kfwebb at bombasticlocution.com
Sent: Friday, 16 April, 2010 02:22
To: MapGuide Users Mail List
Subject: Re: [mapguide-users] building 64bit openmapguide on rhel 5.4

Hi Adam,
Stefano is correct about removing the #ifdef statements in both
Timer.cpp and Core.cpp.

Remove all of the following #ifdef, #else, and #endif (making sure you
remove all of the WIN32 code that is inside the _DWFCORE_WIN32_SYTEM
code blocks:
#ifdef  _DWFCORE_X86_SYSTEM

#ifdef    _DWFCORE_WIN32_SYSTEM
   
#else
#ifdef    _DWFCORE_LINUX_SYSTEM
    
#else
#error    Cannot continue - implementation not provided for this
hardware configuration
#endif
#endif

The only code that should be left is the code that was inside the
_DWFCORE_LINUX_SYSTEM code blocks, some of which you updated for 64-bit
architecture.


KFW



On Thu, 2010-04-15 at 16:14 +0200, Balogh Ádám wrote:
> Dear Kevin Webb,
>  
> Thank you for your valuable help,
>  
> I did everything exactly as you said, but I'm still having the same
> error when building MgDev (see the attachment).
>  
> The dwf libs are compiled smoothly. I checked the
> Server/src/Core/Makefile if -ldwfcore was given for the linker, but I
> found both dwftk and dwfcore was added.
> Now I am hopeless again. If you could share how you could overcome
> with this, I would be realy grateful. 
>  
> Thank you,
> Adam
>  
>  
>  
> Hello Adam, Rajeev, and others interested in 64bit MapGuide,
> 
> I thought I had the problem solved last week. I got FDO and MapGuide
> to
> compile on a x86_64 installation of Fedora Core 8 (a torturous
> experience). When I tested using the Sheboygan.mgp sample data,
> mgserver
> threw an FDO exception related to the ConvertUTF16toUTF32() routine in
> Fdo. It was then that I realized I had contract work to do and I
> didn't
> have the time it would take to do a thorough job on Fdo and any other
> packages needing work, so I stopped my 64-bit installation and
> installed
> on an ancient 32-bit box so that I could get some work done. (I am
> still
> debugging the 32-bit install - nothing is ever easy in this business).
> 
> To answer your direct question, here is how I got around the DWFTimer
> issues. My thinking is that DWF is an Internet Explorer only viewer,
> not
> much use for today's browser market. I also didn't know what other
> dependencies there were for the DWF library so I just wanted to make
> it
> compile and not ever use the viewer. I copied the
> dwfcore/x86/Core.cpp,
> and dwfcore/x86/Timer.cpp files into the dwfcore directory. I then
> edited Timer.cpp to change the 32-bit assembler into 64-bit assembler,
> register name changes only. I added Timer.cpp and Core.cpp to the
> dwfcore Makefile and Makefile.am for the libdwfcore_la_SOURCES tag.
> 
> In general I had to sprinkle around alot of -fPIC directives in
> numerous
> spots, and I changed all of the build_oem.sh entries that were
> --enable-static --disable-shared
> 
> to
> 
> --enable-shared --disable-static
> 
> The change to dynamic linking required adding some -l___ and -L____
> directives as called for.
> 
> I hope to go back to the 64-bit build when I have time, but maybe the
> 2.2 version will be out by then.
> 
> Good luck!
> 
> Kevin Webb
> 
>  
>  
> Balogh Ádám
> adatbázisgazda
> GDS 2000 Kft.
> 1074 Budapest, VII. ker. Dohány u. 20. III/15.
> Telefon: +36-1-344-5495 
> _______________________________________________
> mapguide-users mailing list
> mapguide-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-users

_______________________________________________
mapguide-users mailing list
mapguide-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-users


More information about the mapguide-users mailing list