A while ago I reported the problems encountered with glib and libc when using lazarus on Solaris. Further testing shows that the problem isn't with glib and libc but gld creating apparently a non solaris ABI compatible program. In an fpc program linked with gld a libc malloc will always return a null pointer. The crashes encountered with glib and libc where also linked to malloc, called from g_malloc, returning a null pointer. Readelf -h on a gld linked program shows OS/ABI: UNIX - System V instead of UNIX - Solaris although gld's default script specifies an elf32-i386-sol2 target.
After manually crafting a ld command to use the solaris linker with info from link.res, the resulting program uses malloc without any problems... This explains also why gcc uses the solaris ld and why the corrupted default script in gld from the solaris 11 gnu-binutils hasn't made more noise. Recent Gnu ld postings on mailing lists indicate that gld is still work in progress and far from stable. Since gcc is happily using solaris ld, I guess the pressure to move on is low. So, I'm looking into modifying t_sunos.pas to use solaris ld. When converting link.res to something ld understood I have encoutered a few problems I need some help on:
- ld doesn't use the PATH nor the library paths (-R -L or -Y P,) to find the system.o, etc. All .o files are to be specified as relative or absolute path. Truss confirms this. Gcc also uses absolute paths when calling ld. Other than searching the unit paths in sunos_t.pas and creating the full path, any other suggestion?
- using {$ .res} raises undefined symbol FPC_RESSYMBOL. Where is it defined?
Thanks, Ludo