HI,

I have a problem with libm.so.2 on solaris.
At least my solaris 2.8 box does not have such a library.
Solaris 2.8 has only a lib.so.1 lib.

When softlinking the lib.so.1 to the new version the application runs.
Of course I'm not sure if I generate the right result, as there is no double check required.

---

HI,

I have a problem with libm.so.2 on solaris.
At least my solaris 2.8 box does not have such a library.
Solaris 2.8 has only a lib.so.1 lib.

When softlinking the lib.so.1 to the new version the application runs.
Of course I'm not sure if I generate the right result, as there is no double check required.

None of the work we've received has looked bad, so this seems to work.

I think it would be better to link the binary staticly, so it will work on every system without any user invention.

I think it would be better to link the binary staticly, so it will work on every system without any user invention.

as far as i know boinc doesn't allow static linking. i think it has something to do with how the client loads applications.

I've just updated the solaris binaries, so hopefully it will run more nicely now!

To be honest:
no.

now all WU's abort, even with the trick above.

I just checked, the 1.12 version uses the same new lib:
bash-2.03$ ldd astronomy_1.12_sparc-sun-solaris
libCstd.so.1 => /lib/libCstd.so.1
libCrun.so.1 => /lib/libCrun.so.1
libm.so.2 => (file not found)
libc.so.1 => /lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/lib/cpu/sparcv8plus/libCstd_isa.so.1
/usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1
bash-2.03$

When running standalone to get all infos:
bash-2.03$ ls -l
total 16726
-rwxr-x--- 1 luxcasch other 295520 Dec 11 17:00 astronomy_1.12_sparc-sun-solaris
-rw-r----- 1 luxcasch other 1142 Dec 11 17:00 parameters.txt
-rw-r----- 1 luxcasch other 8240038 Dec 11 17:01 stars.txt
-rw-r----- 1 luxcasch other 50 Dec 11 17:01 volume.txt
bash-2.03$ ./astronomy_1.12_sparc-sun-solaris
bash-2.03$ cat stderr.txt
Can't open init data file - running in standalone mode
set_worker_timer(): pthread_create(): -1
<added missing "\n"for better visibility>
bash-2.03$

Don't know where the problem might be.

Achim

I've just updated the solaris binaries, so hopefully it will run more nicely now!

To be honest:
no.

now all WU's abort, even with the trick above.

I just checked, the 1.12 version uses the same new lib:
bash-2.03$ ldd astronomy_1.12_sparc-sun-solaris
libCstd.so.1 => /lib/libCstd.so.1
libCrun.so.1 => /lib/libCrun.so.1
libm.so.2 => (file not found)
libc.so.1 => /lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/lib/cpu/sparcv8plus/libCstd_isa.so.1
/usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1
bash-2.03$

When running standalone to get all infos:
bash-2.03$ ls -l
total 16726
-rwxr-x--- 1 luxcasch other 295520 Dec 11 17:00 astronomy_1.12_sparc-sun-solaris
-rw-r----- 1 luxcasch other 1142 Dec 11 17:00 parameters.txt
-rw-r----- 1 luxcasch other 8240038 Dec 11 17:01 stars.txt
-rw-r----- 1 luxcasch other 50 Dec 11 17:01 volume.txt
bash-2.03$ ./astronomy_1.12_sparc-sun-solaris
bash-2.03$ cat stderr.txt
Can't open init data file - running in standalone mode
set_worker_timer(): pthread_create(): -1

bash-2.03$

Don't know where the problem might be.

Achim

this looks like a problem with pthreads. i wonder if theres a version problem with that.

this looks like a problem with pthreads. i wonder if theres a version problem with that.

Agreed.
How can I help checking?
The last version was better, so something changed in the way the lib is used, right?

Same for 1.13.

this looks like a problem with pthreads. i wonder if theres a version problem with that.

Agreed.
How can I help checking?
The last version was better, so something changed in the way the lib is used, right?

I updated the makefile a bit, so this might have helped things out. All these version issues seem to be a bit of a headache on linux, so i'm still not quite sure how to get everything to work right for everybody.

this looks like a problem with pthreads. i wonder if theres a version problem with that.

Agreed.
How can I help checking?
The last version was better, so something changed in the way the lib is used, right?

I updated the makefile a bit, so this might have helped things out. All these version issues seem to be a bit of a headache on linux, so i'm still not quite sure how to get everything to work right for everybody.

I updated the makefile a bit, so this might have helped things out. All these version issues seem to be a bit of a headache on linux, so i'm still not quite sure how to get everything to work right for everybody.

Already for 1.13, or something later?

1.13 still uses the luibm.so.2, and has in addition a problem with pthreads(at least on my old system)

I updated the makefile a bit, so this might have helped things out. All these version issues seem to be a bit of a headache on linux, so i'm still not quite sure how to get everything to work right for everybody.

Already for 1.13, or something later?

1.13 still uses the luibm.so.2, and has in addition a problem with pthreads(at least on my old system)

for 1.13. i'm not sure if theres any good way to get the binaries to be dyamically linked. I tried using --export_dynamic as a gcc flag and the problems still seemed to happen.

i'm not sure if theres any good way to get the binaries to be dyamically linked. I tried using --export_dynamic as a gcc flag and the problems still seemed to happen.

Isn't it better to link statically?
You never know what is installed in the target system, so a static version ensures the right (meaning the one which was used during compile time) lib, whuile dynamic linking shinks the exe and you don't know which lib is used.
Of course there might be libbs which should really come from the installed Os (so dynamic link), but I don't know which ones.

I have the impression, that the missling linkage against the lpthread causes this pthread crash problems.
Also, I am not shure now, if a staticly linked and working binary is posible at Solaris. Evtentualy a staticly linked binary could cause crashed at other Solaris releases.
What is about to link the binary dynamicly and include "./" (the projects/milkyway... direcory) in the library search path of the application and send out a file (link) to /usr/lib/libm.so.1 out with the application which is placed in the projects directory . - Also I am not shure if this work, because I am not shure, if the libm.so.1 is existing in the newer Solaris releases.

Edit: other solution could be, to link the application explicit against the /usr/lib/libm.so.1. But it requires, that the libm.so.1 exists on the newer Solaris systems, too.

Do you know who the other projects out there have done this?
There are at least some which have a working client on this box, so they have solved the problem somehow.
I'll check the other apps I have running sucessful on the box, for dynamic linking(What they link).
Is there a way to check if they have any lib statically linked in?

Do you know who the other projects out there have done this?
There are at least some which have a working client on this box, so they have solved the problem somehow.
I'll check the other apps I have running sucessful on the box, for dynamic linking(What they link).

Yes. I guess you are running my BOINC client, my SIMAP and Yoyo apps succesfull on your systems.
I have linked em dynamicly at all libs, including libm.so.1. I have not any reports, that it did not work on Solaris 10. But to make sure that it work on all releases a check of the different libm.so.* on a Solaris 10 system would be needed.

Btw. I recommend you strongly to install the BOINC 5.10.27 package available from www.dotsch.de/boinc. The 5.11.0 had caused some problems at my systems.

Is there a way to check if they have any lib statically linked in?

"strings $FILE | grep lib". But so far I know are only few staticly libs avialable at Solaris.

But to make sure that it work on all releases a check of the different libm.so.* on a Solaris 10 system would be needed.

What do you need:

/lib$ uname -srpiv
SunOS 5.10 Generic_118833-36 sparc SUNW,Sun-Fire-V490
/lib$ ls -l libm.so*
lrwxrwxrwx   1 root     root           9 Apr 10  2007 libm.so -> libm.so.2
-rwxr-xr-x   1 root     bin        23828 Jan 23  2005 libm.so.1
-rwxr-xr-x   1 root     bin       792916 Jan 23  2005 libm.so.2
/lib$

Btw. I recommend you strongly to install the BOINC 5.10.27 package available from www.dotsch.de/boinc. The 5.11.0 had caused some problems at my systems.

Will do. Thanks

Btw. I recommend you strongly to install the BOINC 5.10.27 package available from www.dotsch.de/boinc.

I only see 5.10.17 was this a typo?

Thanks

Btw. I recommend you strongly to install the BOINC 5.10.27 package available from www.dotsch.de/boinc.

I only see 5.10.17 was this a typo?

Thanks

Ups, sorry, was a typo. 5.10.17 is the actual version for Solaris on SPARC.