Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#1291 closed bug (fixed)

Binary Solaris build fails on Solaris 9

Reported by: guest Owned by:
Priority: normal Milestone:
Component: Build System Version: 6.6.1
Keywords: Cc:
Operating System: Solaris Architecture: sparc
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

There doesn't appear to be a libm.so.2 on Solaris 9, just libm.so.1. Any suggestions?

Change History (8)

comment:1 Changed 10 years ago by igloo

Milestone: _|_

I'm not a Solaris expert, but http://www.neowin.net/forum/lofiversion/index.php/t378930.html recommends http://www.blastwave.org/. I know nothing about either site, though.

If the existing binaries can't be made to work on Solaris 9 then you'll have to follow the porting process, but that would probably be more work. If you do have to do so, then using a Solaris 10 box as the host would probably be simplest, if you have access to one.

comment:2 Changed 10 years ago by guest

The fundamental problem is that the GHC binary package was built on a Solaris 9 release with the C99 patches installed. These patches are not publicly available, and many Solaris 9 systems don't have them.

There is no clean fix for this. A very ugly solution is:

  • cd /usr/lib; ln -s libm.so.1 libm.so.2
  • LD_NOVERSION=1 export LD_NOVERSION
  • create a file with stubs for the C99 (float) functions (e.g. sinf()) which invoke the (double) versions, and "ar r" this to libHSbase.a; otherwise programs compiled with the binary GHC will fail to link
  • alter the GHC build sequence to add this object to the *new* libHSbase.a, because GHC assumes the existence of the C99 functions instead of testing and substituting the (double) versions

comment:3 Changed 10 years ago by igloo

Resolution: invalid
Status: newclosed

Here's the end of the previous message with trac formatting:

  • cd /usr/lib; ln -s libm.so.1 libm.so.2
  • LD_NOVERSION=1 export LD_NOVERSION
  • create a file with stubs for the C99 (float) functions (e.g. sinf()) which invoke the (double) versions, and "ar r" this to libHSbase.a; otherwise programs compiled with the binary GHC will fail to link
  • alter the GHC build sequence to add this object to the *new* libHSbase.a, because GHC assumes the existence of the C99 functions instead of testing and substituting the (double) versions

I'm closing this ticket, as it doesn't look like there's a GHC bug here.

comment:4 Changed 9 years ago by guest

Resolution: invalid
Status: closedreopened

Can you please change the website/docs to reflect this?

Either:

  • package is tested and known to work on solaris 10 (this is basically libm.so.2 was introduced to the general public) and remove the reference to solaris 8
  • add the above symlink magic for libm.so.1 and libm.so.2 to either the webpage or the install instructions

Many people reading it will assume it should work for them on solaris 8 and 9 (99%+ of things that work on 8 will work out of the box on 9) -- this is more of a website bug than a compiler bug.

comment:5 Changed 9 years ago by guest

sorry, this is in reference to the current page for 6.8.3, which says

This is a binary distribution for Solaris, known to work on versions 8 and 10

comment:6 Changed 9 years ago by maeder

if someone tells me how to build ghc under Solaris 8 using libm.so.1 only, I could try it (for the next release). I used to get a mere link error for the stage2 compiler without libm.so.2.

comment:7 Changed 9 years ago by igloo

Resolution: fixed
Status: reopenedclosed

I've added a link to this ticket from the 6.8.3 download blurb.

comment:8 Changed 9 years ago by guest

I'm working on getting this working on solaris 8. I will post some notes once/if I get it working.

Note: See TracTickets for help on using tickets.