Any attempts at MongoDB on AIX - mongodb

I have a project for which it would be desirable to run MongoDB on AIX 6.1 on a Power 6 box. AIX is not a supported platform for MongoDB and I will have a bash at building it from source. Has anyone tried this already?
I plan to use GNU G++ 4.2 PPC and I have the latest SCons running on Python 2.6, so the build tools run.
My initial impression is that there are a lot of platform dependencies in the .h files that I have encountered. It does not look like a no-brainer by any stretch to get AIX/Power running. Any words of wisdom whether it is or is not likely to be successful?

You will have to port several things as there is some very specific x86/x86_64 assembly as part of the MongoDB sources: https://github.com/mongodb/mongo/blob/master/src/mongo/platform/atomic_intrinsics_gcc.h Just like with ARM, this is not going to be a trivial task.
See some references:
https://jira.mongodb.org/browse/SERVER-1811
https://github.com/wtfuzz/mongo-arm

Related

Postgresql Debugger on Windows

I've seen the docs to install the debugger on linux machines. But no docs on how to install the debugger on a windows machine. Does anyone know how to do this? Looks like you have to compile the pldebugger somehow.
Thanks
Yes, you'd have to build the pldebugger extension.
Unfortunately, building PostgreSQL extensions on Windows is non-trivial: apart from the requirement of a C compiler, you have to come up with the correct compiler invocation, since the PostgreSQL extension building infrastructure does not work on Windows.
The PostgreSQL community is aware of that deficiency, but it is not easy to come up with solutions for a platform that is so different from all others.

enthought gdal/ogr not built with GEOS?

I'm using the academic version of enthought python for Windows. Most of ogr works, but not geometry methods like geometry.Buffer() or predicates like geometry1.crosses(geometry2). According to this:
http://gdal.org/python/osgeo.ogr.Geometry-class.html#Crosses
ogr needs to have been built with GEOS. Has anybody got these methods to work with Enthought? If not, can you suggest a Windows python binary where these are working?
thanks,
jim
Correct, there are many possible build configurations of GDAL/OGR, and geos is not currently supported by Enthought's build configuration. We will consider adding it in a future build. Meanwhile, FYI, GEOS operations are fully supported in the powerful and popular Shapely package which is included in the Enthought repository.

Is there a MongoDB 2.4+ installation available for Arm chips?

I'm interested in building a small server using the Odroid U3 which has 1.7GHz Quad-Core chip. I did install MongoDB 2.1.1 on a Raspberry but found the performance far too low for any serious usage other than tinkering. I was wondering there is a MongoDB package/instruction/tutorial somewhere to install newer versions of MongoDB. Any suggestion/help would be appreciated
You may use mongodb-linux-armv7l-2.4.1.tgz that I've uploaded, taken from a JIRA comment. An experimental but working build. Not production ready.
There is a really up to date version of MongoDB for Arm chips on ArchLinux. Its currently 2.6.1+ and no need for compiling. Is also production ready - albeit with the limitations MongoDB 32bit has.
As of version 3.4 MongoDb officially supports ARM 64.
One thing to note though: Currently (v3.4.0) Only the Wired Tiger storage engine is currently supported.
The current version can be downloaded here: https://fastdl.mongodb.org/linux/mongodb-linux-arm64-ubuntu1604-3.4.0.tgz
You may watch this thread on Github of DietPi for update.
For now I have tested prebuild MongoDB 3.0.14 Binaries for Odroid XU4 Running DietPi_OdroidXU4-ARMv7-Jessie and it is working fine. Pl check bellow screenshot.
MongoDB 3.0.14 Running on Odroid XU4 on DietPi V6.10 (Debian Jessie):

JProfiler on Centos 5.7 `GLIBC_2.7' not found

JProfiler agent seems to require glibc 2.7, but Centos has glibc 2.5. Has anyone successfully compiled the jprofiler agent for glibc 2.5 or did previous version of JProfiler create agents with 2.5?
Actul error is
Error occurred during initialization of VM
Could not find agent library /opt/jprofiler/bin/linux-x64/libjprofilerti.so in absolute path, with error: /lib64/libc.so.6: version `GLIBC_2.7' not found (required by /opt/jprofiler/bin/linux-x64/libjprofilerti.so)
The problem is that JProfiler you are using has been built on a system with glibc-2.7 (or later).
In general, UNIX systems support backwards compatibility (code compiled on an older system continues to work on a newer one), but not forward compatibility (you can't expect code built on a newer system to work on an older one).
Your choices are: upgrade your version of glibc, or obtain a different build of JProfiler (that was built on glibc-2.5 based system or older).
That's actually a regression in 7.0.1, an easy workaround is to use 7.0:
http://download.ej-technologies.com/jprofiler/jprofiler_linux_7_0.tar.gz
We'll fix this dependency problem shortly (my company develops JProfiler). Thanks for letting us know.

Creating installers for complex cross-platform programs

I'm sketching an application deployment process for a bunch of relatively complex desktop applications. We have both native and Java apps, so the deployment must be able to check for existence of the JRE and install it if needed. Some of the apps depend on special hardware, so the deployment must also be able to launch the necessary driver installers. Some of the apps are multiplatform, and preferably the same mechanism should be able to create Windows, Linux and Mac OS X installers. That is:
The installer must be able to install, in addition to the application itself:
Java Runtime Environment.
Drivers (hardware) - that is, launch other installers.
The installer builder must be operable from the command line so that it can be integrated with an automatic build mechanism that generates installer packages for each platform as nightly builds.
In addition, I need to create "update from the web" mechanisms for the applications. It could be included in the installer, or it could also be a separate custom mechanism built into the application.
Now, this is getting a bit complex, and I suspect that there might be no single installer that could do this all. Therefore I'm thinking between two fundamentally different approaches:
Platform-specific mechanisms: NSIS would create .exe or .msi for Windows, XXX would create .deb for Ubuntu, and YYY would create .dmg for OS X.
Cross-platform installer that would handle all the requirements above: ZZZ?
Any recommendations? Some options that I've looked include:
NSIS - Excellent, but Windows only.
IzPack - Good, but requires JVM to run.
Is there an universal tool for this, or should I just pick an appropriate tool separately for each platform? In the latter case, what would be "NSIS equivalents" for Ubuntu and Mac OS X?
I have some recommendations as follows.
Use WIX (Windows Installer XML) for creating MSI installers for Windows
Use Package Maker (part of XCode tools) on MAC OS X, preferably the command line version
Write wrapper scripts (in Python or so) to drive the over-all installer creation process.
to aggregate all the components you need to install (may be from ur version control system)
generate necessary files for Wix and Package Maker as much as possible
to run the packaging tool and generate the package
Make sure that the overall installer creation process is a simple one command operation overall (with options to create different versions of your package based on criteria like release branch etc.)
Overall, developing this workflow requires some initial effort and quite a lot of thinking. But the end result is quite worth the effort.
I haven't done this on the Linux side, but I guess would use RPM/DEB on that front in this workflow.
BitRock InstallBuilder meets all the requirements, including being multiplatform and providing an autoupdate mechanism
You should take a look at InstallJammer. It will definitely handle the cross-platform elements that you want and can even add entries to the DEB and RPM databases on the target system during installation. OS X support is still experimental, but it mostly works.