Software ports galore!

A couple of weeks ago I wrote about the port of dtrace that Colin and I have got up and running under Neutrino.   For the most part, porting software to Neutrino is a pretty straightforward matter.  Since Neutrino runs self-hosted (ie you work and build in the same environment that you deploy) it means that all of the ‘configure/make’ style projects work without too much hassle.  In fact most of the time if the source is coming from Linux, *BSD, Solaris or some other unix flavour you can get it up and running in a couple of hours.  The main challenge is almost always figuring out the build system and making sure that our compiler front end (qcc) is used to pick up all of the required environment bits and that hacks for other systems are really required for Neutrino (which is pretty well behaved).

Having ported software on a self-hosted system is pretty much essential for a software developer to work effectively.  There are so many essential software bits and pieces that QNX would never include with the Neutrino SDK because while they are useful, the SDK is targeted specifically at what is needed to build Neutrino applications and needs to be portable (and consistent) for use under Windows, Linux, Solaris as well as Neutrino self-hosted x86.   That doesn’t mean that the extra software bits aren’t useful, and historically a 3rd party CD was provided for Neutrino self-hosted developers that came with loads of useful extras, from scripting languages (perl, python, tk) to web servers (apache) and editors (vim).

A couple of developers here at QNX, Sean B. and Xiaodan T., with the help of some QNX community members have been working on a wicked awesome project that pretty much replaces the 3rd party CD with something even better!  They have been working to port the BSD pkgsrc tool/project to support the QNX Neutrino self-hosted environment.   Just the other day I got a message in my mailbox indicating that the project had hit a critical milestone and that QNX Neutrino was now considered a full fledged supported platform:

“we are proud to welcome QNX, thanks to Sean Boudreaux.”  http://mail-index.netbsd.org/pkgsrc-users/2007/10/15/0005.html

It is even listed on the projects main documentation page … now that is super cool news!  There are 7000+ different software packages part of this collection, and to have all of them available pre-ported and on-demand is a pretty awesome feat.

So if you are running Neutrino self-hosted, (and why wouldn’t you be!) and you want more than just the stock installed software, then you should definitely take a look at the pkgsrc community project

Congratulations and thanks to Sean, Xiaodan and all the others who’ve been working on getting this up and running!

Thomas

Advertisements

4 comments so far

  1. Mario on

    “So if you are running Neutrino self-hosted, (and why wouldn’t you be!)”

    Because the IDE is one version behind the windows version and much much slower.

  2. JMK on

    “Because the IDE is one version behind the windows version and much much slower.”

    …and all the other tools (source control client, UML auto-code-generating modeling tool, etc.) are Windows-only for us. :-(

    You know what would be even cooler than pkgsrc on self-hosted x86 Neutrino? Pkgsrc that magically lets me cross-compile to other architectures. That way, when I want to get some configure/make thing built for my PowerPC target, I don’t have to go through the pain of trying to debug some silly autoconf/pkgtool/libtool/whatever junk. (Sometimes they “just work”, sometimes they just don’t for some obscure reason)

  3. Malte on

    I know many people who tried to run Neutrino self-hosted but the IDE causes so much trouble that they went back to Windows.

  4. Will Miles on

    “all of the ‘configure/make’ style projects work without too much hassle.”

    Sure, if by ‘without too much hassle’ you mean ‘takes up to about a day or so per package to sort out autoconf/libtool brokenness’. Just this weekend I had the misfortune of needing to build libSDL, for which QNX is technically a supported target; it took me most of the day to convince the build system that yes, QNX does indeed support shared libraries – and even then I ultimately resorted to hand-hacking the local copy of libtool. Many small things contribute to this problem, like the broken patch and ksh that are shipped with the current release, fortunately the first things fixed in the pkgsrc port; fully functional autoconf/libtool support would go a long way further.

    A related problem is that even self-hosted Neutrino environments still suffer from multiple personality syndrome at times – for example, are we cross-compiling for the target platform in /usr/qnx630/targer, or are we compiling for the ‘local’ system (/usr, /usr/local, /opt, etc.)? As JMK notes, it’e even worse if you should want to do cross- or multi-target compilation (like, for example, the ported tools in the core_os tree) – then you’re stuck mutating the build environment even further.

    All that said, pkgsrc support is still a huge step forward and all of the above problems are solvable – keep up the good work!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: