Got Lazarus up and running on Solaris 10 9-10 (x86) with the gtk2 widgetset. Gdb 6.8.
It's not perfect ( a SIGSEGV in Tproject.UpdateUnitComponentDependencies when closing a project) but it runs and debugs programs correctly. I'm actually running lazarus from inside the lazarus IDE to debug the SIGSEGV.

If anybody interested I'll write a small howto.

Ludo

/Very/ well done :-) Please do write it up, particularly if you have a record of what libraries you had to pull in (SFW or whatever).

I was thinking of getting a SPARC Solaris 11 Express from Oracle at some point, when I last looked Open Solaris (or whatever it's called now) was x86-only.

Maybe an entry in the WIKI would be a good idea.

Michael.

/Very/ well done :-) Please do write it up, particularly if you have a record of what libraries you had to pull in (SFW or whatever).

This is the procedure to get lazarus trunk and fpc trunk up and running starting from a clean system (adapt to your processor, I'm on x86):

-Get and install fpc 2.4.4 from
http://www.freepascal.org/down/i386/solaris-ftp.freepascal.org.var

-Install following packages from http://sunfreeware.com/. This is a long list because gnu binutils, make, subversion (a lot of dependencies) and gtk2 are pulled in:
apache-2.2.19
atk-1.18.0
binutils-2.21.1
cairo-1.4.10
coreutils-8.11
expat-2.0.1
fontconfig-2.8.0
freetype-2.4.2
gcc-3.4.6
gdb-6.8
glib-2.25.13
gtk+-2.12.0
jpeg-8a
libiconv-1.13.1
libintl-3.4.0
make-3.82
ncurses-5.7
neon-0.29.5
openldap-2.4.24
openssl-1.0.0d
pango-1.18.2
render-0.8-sol10-intel-local
renderproto-0.9.3
sasl-2.1.21
subversion-1.6.12
tiff-3.9.4
xft-2.1.2-sol10-intel-local
xrender-0.8.3-sol10-intel-local
zlib-1.2.5

These versions are all available for SPARC.

-export PATH=/usr/local/bin:$PATH (in the beginning of the path to get the gnu binutils)
-export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH

-run gtk-demo to check your GTK2 installation

-get fpc from svn.
make clean all
make install INSTALL_PREFIX=/usr
Nothing special, /etc/fpc.cfg installed with 2.4.4 is fine for 2.5.1.

-get lazarus from svn.
make clean all OPT="-k-lumem"
There is a problem with the solaris libc and glib2. Lazarus crashes with a "Glib-Error (recursed) ** :gmem.c:140: failed to allocate 42 bytes". Strangely enough, when testing the different packages from SFW, I got at one point into the strange situation that lazarus ran but every program created with lazarus crashed with this error. There is something non-repetitive in the problem. I tried debugging this and found out that, when breaking on gtk2int.pas:INTERNALINIT, just before the crash point, calling g_malloc(42) failed while malloc(42) was ok. The solution I found is to use libumem which is the "better" memory manager for Solaris and shipped standard since Solaris 9 update 3. Running lazarus with "LD_PRELOAD=libumem.so ./lazarus" solved the problem. Hence the make option OPT="-k-lumem" to load libumem before libc. Note that the parameter -k-lumem needs to be added to every lazarus project. Without, the program will run fine in the IDE but crash when ran standalone. Adding {$linklib umem} to the program has the same affect.

-enjoy lazarus! (configure for fpc 2.5.1 and rebuild if that is what you want)

So far only 1 problem: when closing all editor files or opening another project I'm getting an accessviolation at line 4683 of project.PP. This is in procedure Search in TProject.UpdateUnitComponentDependencies. I'm trying to debug this. TypeInfo:=TypeData^.ParentInfo seems to return garbage...

Can you update us on how this works on SPARC? If that goes well, I'll turn this into a wiki page.

Ludo

[...]

Can you update us on how this works on SPARC? If that goes well, I'll turn this into a wiki page.

I think it would be worth knocking that into a wiki page, then when I've got time I can either write a parallel one for SPARC or annotate yours.

Noting your comment in fpc-devel that "sunfreeware.com supports up to solaris 10" I ought to stop beating about the bush, do the upgrades and see if I can get Lazarus going on SPARC Solaris 10. But I'm also trying- with very limited success- to put time into MIPS.

Here it is : http://wiki.lazarus.freepascal.org/Lazarus_on_Solaris I added a Solaris 11 Express paragraph as it is quite different from 10 and coming with its own little problems (the bug in ld from the official gnu-binutils for example).

Ludo

If I'm reading that properly you're using FPC 2.5.1, but what (numeric) version of Lazarus?

I'll probably start off with the compiler etc. I've got working here, I had problems with install.sh which I described in bug report 0018271.

I'm trying to put some time into the SPARC side, now that you've pointed out that SFW is applicable to 10 not 11. I'll be back.

If I'm reading that properly you're using FPC 2.5.1, but what (numeric) version of Lazarus?

First line says lazarus svn and fpc svn. Trunk lazarus is 0.9.31.

Reason for using svn is the patch commited recently to solaris rtl and to get the non-commited alignment patches to Lazarus, attached to bug http://bugs.freepascal.org/view.php?id=19109, working. These patches will probably not work on earlier lazarus releases.

I'm trying to put some time into the SPARC side, now that you've pointed out that SFW is applicable to 10 not 11. I'll be back.

11 is quite a different beast compared to 10. It comes with a package manager that pulls in dependencies automatically from an official repository, much like other linuxes have been doing for years. All the packages pulled in from SFW for 10 are available in 11 from the official solaris repository. So that shouldn't stop you form try 11 express. However, the gnu-binutils from repository being bugged and only at version 2.19 while SFW offers 2.21.1, which is the latest full source release, raises the question whether a parallel source, such as SFW, isn't going to pop up quickly.

Ludo

Subject to one minor glitch the alignment patches are fine on 0.9.30.

Thanks, noted. I'm planning to work on 10 since that's what I've got.

Foud out that the glib/libc crash is linked to the use of gnu ld. Using the solaris linker with the undocumented fpc "-Xn" option solves the problem and makes the "-k-lumem" solution obsolete. I'll update the wiki accordingly.

Ludo

For the record, working on a freshly-built system (SPARC Debian "Lenny"
+ KDE) and based on yesterday's FPC 2.4.5 snapshot, Lazarus 0.9.30 works fine with your align_all.diff except for one benign patching error (code does not yet exist). Lazarus trunk (31775) IDE appears OK but I think somebody was tweaking the LCL when I pulled it.

If anybody else is considering looking at this then avoid SPARC Debian "Squeeze" + KDE which doesn't appear to be reliable yet.

Still trying to find time to get onto SPARC Solaris.

Currently working on the Wiki. I've split out the packages needed for Subversion, I built it on an older server a few weeks ago and experience suggests that it's going to be easier to build a client from source rather than pulling in Apache etc.

What version of the libpng package have you got (and what's the command to check)? I'm getting

Linking ../lazarus
/usr/local/lib/libcairo.so: undefined reference to `png_set_expand_gray_1_2_4_to_8'

and since Cairo's been updated I suspect libpng should be as well.

That is indeed a problem with packages: you pull in a lot of unused stuff. Subversion client uses libapr and libaprutil which is in the apache package. Don't know if you can get around that dependency by building from source.

The libpng package on my system is 1.2.44. It seems I forgot to add this package to the list of packages to install.

To confirm the installed version:

$ pkginfo -il | less

Type /libpng to locate.

Cairo uses libpng12.so. /usr/local/lib/libpng12.so.0 points to libpng12.so.0.44.0

What is weird though is that the original solaris
/usr/lib/libpng12.so.0.38.0 has png_set_expand_gray_1_2_4_to_8. I'm not sure anymore why I installed the libpng from SFW and if it was needed for lazarus or something else I installed later.

Ludo

Confirmed that lazarus links and runs ok with original /usr/lib/libpng12.so.0.38.0.

What is the libpng version when you do a ldd /usr/local/lib/libcairo.so ?

Ludo

It needed libapr, but that was available as a secondary subversion-deps source bundle. Getting a standalone svn server running locally was a bit of a no-brainer, I /really/ didn't want to risk messing up the version of Apache on the system in question.

That's what I was thinking, but I wanted to check.

On a clean SPARC system,

PKGINST: SUNWpng
NAME: Portable Network Graphics library
CATEGORY: GNOME2,application,JDS3
ARCH: sparc
VERSION: 20.2.6.0,REV=10.0.3.2004.12.15.14.11

It looks as though this is installed in /usr/lib, so if I understand things correctly installing libpng from SFW should put a newer version in /usr/local. Let's hope the result isn't too sensitive to path misconfiguration.

What is weird though is that the original solaris /usr/lib/libpng12.so.0.38.0 has png_set_expand_gray_1_2_4_to_8. I'm not sure anymore why I installed the libpng from SFW and if it was needed for lazarus or something else I installed later.

There's a possibility that you've got more updates in your Solaris than I have. I'm using a set of CD-Rs that somebody in Sun marketing sent me which I find conveniently robust without a great deal of patching, I'm in no great hurry to raise my head above the parapet as far as Sun/Oracle are concerned :-)

Same version on x86. Build date is one day off: REV=10.0.3.2004.12.16.14.42

That is where LD_LIBRARY_PATH comes in. /usr/local/lib is first. Note that I had a problem when adding /usr/local/lib to LD_LIBRARY_PATH in .bashrc. JDS didn't like it and complained about nautilus and panel not being able to register on DBUS, leaving me with an empty desktop when logged in...

Ludo

libpng12.so.0 => /usr/lib/libpng12.so.0

One of the (few) other things I'm having trouble with is running gtk-demo, but I was going to leave detailed investigation of that until after I'd got compilation sorted out.

No fonts found; this probably means that the fontconfig library is not correctly configured. You may need to edit the fonts.conf configuration file. More information about fontconfig can be found in the fontconfig(3) manual page and on http://fontconfig.org

It doesn't exist- by default at least- on the Debian systems I've got here, so I've got little to compare the Solaris GTK setup with.

Probably an older libpng12.so.0 on SPARC.

When you have installed fontconfig you'll have the fc-list command that lists the fonts available.
On my system I have fonts in /usr/openwin/lib/X11/fonts with links from /usr/X11R6/lib/X11/fonts and /usr/X11/lib/X11/fonts. Check in /etc/fonts/font.conf if the correct dir is specified. I don't have the fontconfig command neither.

Ludo

Adding libpng from SFW results in compilation/linkage completing. I'm updating the wiki as I progress.

Lazarus starts running subject to LD_LIBRARY_PATH being correct, but bombs with the font problem.

Hopefully more in the morning.

fc-list run as myself (i.e. non-root) returns nothing. Run as root it returns a list of fonts. Run as root with LD_LIBRARY_PATH=/usr/local/lib returns nothing. Think I've got a problem here...

One positive thing that I can report is that lazbuild --help returns sensible output, even using the default (GNU?) linker.

The situation appears to be that there are two distinct fontconfig systems, e.g.

/usr/bin/fc-list
/etc/fonts.conf

and

/usr/local/bin/fc-list
/usr/local/etc/fonts.conf

I can't simply do a hack like symlinking the two fonts.conf files together, something's incompatible at a lower layer.

I'm going to check that make bigide works, but apart from that I think it needs the involvement of somebody with more SPARC/Solaris experience than I've got, e.g. whoever was asking about the availability of a port on StackOverflow a few months ago.

It's not so much that I can't afford to put much more time into this one, but that to have something manageable it needs to be predictable, i.e. while installing a sequence of SFW packages is OK in principle it's not going to benefit Lazarus if that breaks things, or if the result still needs an indeterminate amount of tweaking before it works.

One positive thing that I can report is that lazbuild --help returns sensible output, even using the default (GNU?) linker.

Same on my system. Except that fonts.conf resides in etc/fonts/fonts.conf.

When you install fontconfig (from SFW) it assumes fonts are installed in /usr/X11R6/lib/X11/fonts.
This is also the directory I find in /usr/local/etc/fonts/fonts.conf. But on my system, as indicated earlier, this directory contains symlinks to the /usr/openwin/lib/X11/fonts subdirs.
The fact that you have different results as root and user is because you adapted probably your PATH as user to include /usr/loc/bin. Which fc-list gives you probably a different result as root and as user. If you run /usr/local/bin/gtk-demo as root it will probably run.

The simplest solution to your problem is to change or add the <dir>/usr/openwin/lib/X11/fonts</dir> entry in
/usr/local/etc/fonts/fonts.conf

I can't simply do a hack like symlinking the two fonts.conf files together, something's incompatible at a lower layer.

Agree.

Please try above. You're almost there.

The error came up when initialising the gtk+ engine...

Typo on my part, should read /etc/fonts/fonts.conf. I'll have another session later.

Ludo, in your instructions for Intel you've got an FPC= shell variable: should that be PPC=?

I think we might need to point out that export is a Bashism.

Ludo, in your instructions for Intel you've got an FPC= shell variable: should that be PPC=?

FPC= is a synonym of PP=, no?

I think we might need to point out that export is a Bashism.

It is posix (http://www.unix.com/man-page/POSIX/1posix/export/). You're right sh in Oracle doesn't support the 'export name=value' syntax. It needs a 'set name=value' and then a 'export name'.

Ludo

No. PP= the compiler. "ppc*.exe" with *=target architecture

FPC= the frontloader binary that can select between different compilers depending on parameters.

I don't know PPC=

But in simple cases

> I think we might need to point out that export is a Bashism. >

A bournism. Plain Bourne sh (not Bourne *Again* sh) supports it too. (ash, BSD sh)

I'm not a makefile specialist but when I read

ifndef FPC
ifdef PP
FPC=$(PP)
endif
endif

and $(PP) isn't used anymore in the remainder of the makefile, I have to admit that I don't understand your comments.

Is

make clean all OPT="-Xn -k-L/usr/local/lib"
FPC=/usr/lib/fpc/2.5.1/ppc386

not the same as

make clean all OPT="-Xn -k-L/usr/local/lib"
PP=/usr/lib/fpc/2.5.1/ppc386

?

Ludo

I have read and understood the same. PP= and FPC= just being aliases for the same thing in the make files.

Regards,
- Graeme -

[Checks] My apologies, I did mean PP.

I can confirm that is the case.

The simplest solution to your problem is to change or add the <dir>/usr/openwin/lib/X11/fonts</dir> entry in /usr/local/etc/fonts/fonts.conf

No, the simplest solution is

# pkgrm SMCfontc

Lazarus now running on SPARC Solaris, subject to an internal exception that I'll investigate in the morning.

Appears to be Intel-specific, unless it's caused by patches which are on your system but not mine. Considering the discussion a week or so ago, I suspect that the Intel-architecture SFW binutils has been crossbuilt on a BSD system.

Using FPC 2.4.4 and compiling Lazarus with bigide:

Lazarus 0.9.30: runs but raises an internally-handled exception ("Illegal character in format string") when invoking the options dialogue.

Lazarus 0.9.30.1 (31593): as above. If a consistent ~/.lazarus directory is supplied might be OK.

Lazarus 0.9.31 (31821, current trunk): as above, but since the FPC sources directory etc. is prompted for by a dialogue at startup it's able to build simple programs- I've not tried anything complex yet.

TApplication.HandleException Illegal character in format string Stack trace:
$000736FC STOREFORMAT, line 978 of
/export/home/local-src/fpc/fpcbuild-2.4.4/fpcsrc/rtl/objpas/sysutils/dati.inc $00072E20 FORMATDATETIME, line 796 of
/export/home/local-src/fpc/fpcbuild-2.4.4/fpcsrc/rtl/objpas/sysutils/dati.inc $00DB81E0 TFFILES__READSETTINGS, line 100 of
/export/home/local-share/lazarus-trunk/components/jcf2/Ui/Settings/frFiles.pas $007F4780 TRAVERSE, line 244 of ideoptionsdlg.pas

I don't see this one on Linux or Windows. I'll investigate a later compiler, although the last time I did I hit a problem due to conditionals in the Lazarus source being confused by the FPC version.

You need to get the latest clocale.inc from svn or the patch from http://bugs.freepascal.org/view.php?id=19675

Ludo

If there is a difference it will be in the rtl/ rtl/os and compiler/ dir

And if there is a difference is related to cross-architecture crosscompiling. It could be that the makefiles construct their own ppc<x> names though.

If you are really interested, search if -P is ever passed to FPC, in any makefile. Since that param only works for fpc.exe and not for ppc386.exe

You've been busy :-)

0.9.30.1 runs but trying to build a simple program can't find its own StdCtrls- I think this is a CodeTools problem peculiar to SPARC Solaris, and is either fixed or probably not worth investigating.

Trunk (0.9.31, 31821) appears to be OK.

I'm not sure whether I'm seeing things, but trunk appears to (re)build the LCL when it compiles its first project.