Thank you for all the answers, I am sure it has something to do with this crypt shared library as when I replace the /lib64/libcrypt.so with the OpenSuse 12.1 version tkmedit can start. This is though a bit risky as there may be other routines including the operating system, that uses the new updated library.

Unfortunately, the proposed solution about copying the libcrypt.so to freesurfer/lib and then add that path to the $LD_LIBRARY_PATH does not work. Any other idea about how to make the old libcrypt.so accessible to freesurfer routines?

Thanks Claus

On 11-06-2013 20:00, Z K wrote:

Thank you Nick for informing the list of this workaround.

-Zeke

On 06/11/2013 01:48 PM, Nick Jones wrote:

...

Regarding any license issue under Opensuse 12.3 and the libcrypt incompatibility.

So grab a libcrypt from an older opensuse (one where freesurfer was working, for me, I used libcrypt.so from 11.3, but 12.1 may be a better candidate if it works). Place it somewhere ($FREESURFER_HOME/lib is a good candidate), then add the location to the LD_LIBRARY_PATH environment variable so that freesurfer finds the old libcrypt.

There is another workaround but you must contact Nick Schmansky, I don't remember the details.

Thanks

Nick

The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

Yes, I agree. Setting/appending to the LD_LIBRARY_PATH should be the last thing you do just before issuing a freesurfer command. At the moment Im unsure of the details regarding various Freesurfer scripts, and their ability to retain environment variables, but I would guess that information is preserved since knowledge FREESURFER_HOME and SUBJECTS_DIR is so often required.

If the /etc/csh.cshrc.local works than that is a good method as well.

We will be looking into this Opensuse 12.3 libcrypt incompatibility, but shy of a new release of freesurfer (which is very unlikely) the solution will almost certainly involve using the older version of libcrypt and setting the LD_LIBRARY_PATH.

-Zeke

On 06/12/2013 01:01 PM, Nick Jones wrote:

Hi Claus,

I don't know what to say, it worked for me.

Make sure the permissions on the library file are ok, and confirm that the LD_LIBRARY_PATH path is set properly before launching the freesurfer command (the system should check that first). I'm not sure if when launching certain commands, freesurfer creates new shells that don't have the variable set properly, which breaks it. I set mine at shell invocation using /etc/csh.cshrc.local and so that may make the difference, but as you say, it is risky to override the system libcrypt.so

Thanks

Nick

On 06/12/2013 02:53 AM, Claus Svarer wrote:

...

Thank you for all the answers, I am sure it has something to do with this crypt shared library as when I replace the /lib64/libcrypt.so with the OpenSuse 12.1 version tkmedit can start. This is though a bit risky as there may be other routines including the operating system, that uses the new updated library.

Unfortunately, the proposed solution about copying the libcrypt.so to freesurfer/lib and then add that path to the $LD_LIBRARY_PATH does not work. Any other idea about how to make the old libcrypt.so accessible to freesurfer routines?

Thanks Claus

On 11-06-2013 20:00, Z K wrote:

...

Thank you Nick for informing the list of this workaround.

-Zeke

On 06/11/2013 01:48 PM, Nick Jones wrote:

...

Regarding any license issue under Opensuse 12.3 and the libcrypt incompatibility.

So grab a libcrypt from an older opensuse (one where freesurfer was working, for me, I used libcrypt.so from 11.3, but 12.1 may be a better candidate if it works). Place it somewhere ($FREESURFER_HOME/lib is a good candidate), then add the location to the LD_LIBRARY_PATH environment variable so that freesurfer finds the old libcrypt.

There is another workaround but you must contact Nick Schmansky, I don't remember the details.

Thanks

Nick

The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

Thanks for the update... Glad it works.

-Zeke

On 06/13/2013 03:07 AM, Claus Svarer wrote:

Thanks again for the answers, I have now got it working. It was my fault, I thought the name should be libcrypt.so and not as I found out it should be libcrypt.so.1.

So the solution for OpenSUSE 12.3 (64 bit) is to copy e.g. /lib64/libcrypt-2.14.1.so from an OpenSUSE 12.1 installation to <freesurfer_home>/lib. and then make a symbolic link to that, like "ln -s libcrypt-2.14.1.so libcrypt.so.1" (also in <freesurfer_home>/lib). Actually the LD_LIBRARY_PATH already included this directory (even two times) while I have the command "source $FREESURFER_HOME/SetUpFreeSurfer.sh" in the .profile (we are using bash shell).

Thanks for the help

Claus

On 12-06-2013 19:13, Z K wrote:

...

Yes, I agree. Setting/appending to the LD_LIBRARY_PATH should be the last thing you do just before issuing a freesurfer command. At the moment Im unsure of the details regarding various Freesurfer scripts, and their ability to retain environment variables, but I would guess that information is preserved since knowledge FREESURFER_HOME and SUBJECTS_DIR is so often required.

If the /etc/csh.cshrc.local works than that is a good method as well.

We will be looking into this Opensuse 12.3 libcrypt incompatibility, but shy of a new release of freesurfer (which is very unlikely) the solution will almost certainly involve using the older version of libcrypt and setting the LD_LIBRARY_PATH.

-Zeke

On 06/12/2013 01:01 PM, Nick Jones wrote:

...

Hi Claus,

I don't know what to say, it worked for me.

Make sure the permissions on the library file are ok, and confirm that the LD_LIBRARY_PATH path is set properly before launching the freesurfer command (the system should check that first). I'm not sure if when launching certain commands, freesurfer creates new shells that don't have the variable set properly, which breaks it. I set mine at shell invocation using /etc/csh.cshrc.local and so that may make the difference, but as you say, it is risky to override the system libcrypt.so

Thanks

Nick

On 06/12/2013 02:53 AM, Claus Svarer wrote:

...

Thank you for all the answers, I am sure it has something to do with this crypt shared library as when I replace the /lib64/libcrypt.so with the OpenSuse 12.1 version tkmedit can start. This is though a bit risky as there may be other routines including the operating system, that uses the new updated library.

Unfortunately, the proposed solution about copying the libcrypt.so to freesurfer/lib and then add that path to the $LD_LIBRARY_PATH does not work. Any other idea about how to make the old libcrypt.so accessible to freesurfer routines?

Thanks Claus

On 11-06-2013 20:00, Z K wrote:

...

Thank you Nick for informing the list of this workaround.

-Zeke

On 06/11/2013 01:48 PM, Nick Jones wrote:

...

Regarding any license issue under Opensuse 12.3 and the libcrypt incompatibility.

So grab a libcrypt from an older opensuse (one where freesurfer was working, for me, I used libcrypt.so from 11.3, but 12.1 may be a better candidate if it works). Place it somewhere ($FREESURFER_HOME/lib is a good candidate), then add the location to the LD_LIBRARY_PATH environment variable so that freesurfer finds the old libcrypt.

There is another workaround but you must contact Nick Schmansky, I don't remember the details.

Thanks

Nick

The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

---

Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer