Error: can't find package itk 3.3 about insight HOT 14 CLOSED

Obviously, this is a tcl/tk package search path problem.
The search paths are provided by tcl/tk.
Insight has some minimum version requirement and error-reported version is only the lowest needed.
Insight is also tolerant on upper/lower case characters in package names.
I do not use Ubuntu, so I can't really help you about it.
IMHO, the "cooking" you made about /usr/local should not been needed if the tcl/tk/itcl/itk/iwidgets packages provided by your OS are OK.
LD_LIBRARY_PATH is only for shared library loading.
On Fedora, the configure command line in README gives satisfactory results, providing all needed packages (from standard distro) are installed. It also shortens the compilation time by disabling binutils parts that are not needed.
You may subscribe to the insight mailing list (https://www.sourceware.org/insight/mailinglist.php) and ask your question there: there might be some people using ubuntu and able to help you better than me.

from insight.

I remember now I had a similar problem a long time ago and the fix had to be made in itk.
Look at https://bugzilla.redhat.com/show_bug.cgi?id=1105506. the itk patch is http://pkgs.fedoraproject.org/cgit/rpms/itk.git/tree/itcl4.0.0-linuxloading.patch. Maybe ubuntu did not yet apply it...

from insight.

@monnerat Thank you for responding. I ll apply that patch and try again. However there must be a simpler way to pass library path, I am not a programmer, so I have to follow trial and error method.

By the way, I don't know why but in /configure process macros tend to find libraries at /usrl/local/... instead of in system' path in my distro. So whenever I get an error in /configure process I rename ./usr/local I think I modified some settings so /usr/local takes the precedence.
Please look at this:

./configure
checking for correct TEA configuration... ok (TEA 3.9)
configure: configuring itcl 4.0.3
checking whether ln -s works... yes
checking for Tcl configuration... found /usr/local/lib/tclConfig.sh
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for existence of /usr/local/lib/tclConfig.sh... loading
checking platform... unix
configure: --prefix defaulting to TCL_PREFIX /usr/local
configure: --exec-prefix defaulting to TCL_EXEC_PREFIX /usr/local
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking how to run the C preprocessor... gcc -E
checking whether make sets ... yes
checking for ranlib... ranlib
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking if the compiler understands -pipe... yes
checking whether byte ordering is bigendian... no
checking for sin... no
checking for main in -lieee... yes
checking for main in -linet... no
checking net/errno.h usability... no
checking net/errno.h presence... no
checking for net/errno.h... no
checking for connect... yes
checking for gethostbyname... yes
checking dirent.h... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking float.h usability... yes
checking float.h presence... yes
checking for float.h... yes
checking values.h usability... yes
checking values.h presence... yes
checking for values.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking for Tcl public headers... /usr/local/include
checking for Tcl private include files... configure: error: Cannot find private header tclInt.h

As you notice it found /usr/local/lib/tclConfig.sh

Luckily renaming /usr/local fixes it.

from insight.

Look at the example: the configure command begins by:

./configure --prefix=/usr/.

The --prefix option should resolve your /usr/local problem. Please note the syntax "/usr/." rather than "/usr": this resolves another binutils-gdb configuration problem.

In addition, I would'nt try to compile and/or use insight on a system with multiple tcl/tk installations...

from insight.

Did you succeed since your last post ?
If yes, can we know what was the problem and how you fixed it.
Can I close the issue ?
Thanks for your feedback.

from insight.

I'm sorry I'm late at responding, unfortunately the problem still persists. Maybe I miss something important. I gave up. So, it's up to you if you close the issue.
Thank you for all your help.
Regards.

from insight.

If you still want to try again:

• For the /usr/local problem, you can force the tclConfig.sh and tkConfig.sh search paths using --with-tcl= and --with-tk=.
• For the "can't find package itk 3.3" runtime error, I'm pretty sure this is a problem similar to https://bugzilla.redhat.com/show_bug.cgi?id=1105506 that can only been fixed in the itk package. I suggest you try the "steps to reproduce" from this bug, and also try with "package require itk" (lowercase i). This is independent of insight and will show you if it's the same itk bug you suffer from or not. You can also try to play with the "ITK_LIBRARY" environment variable at insight run-time.

Lastly I suggest you ask help from ubuntu people: file an itk bug report if the test above is positive, or even maybe someone there may generate an insight package for you... or the entire community.

I'll close this bug in a week if no new post occurs. Sorry I'm not able to help you more.

from insight.

Thank you for additional info, you are very helpful. I have some health problem and I am getting late at feeding back. I checked itk.tcl file, it's present in /usr/share/tcltk/itk3.3/itk.tcl , I tried export ITK_LIBRARY=/usr/share/tcltk/itk3.3 & insight and the result is the same.

and also try with "package require itk" (lowercase i)

Where should I insert it?

from insight.

I tried export ITK_LIBRARY=/usr/share/tcltk/itk3.3 & insight and the result is the same.

If you used '&', commands have been submitted in parallel, so ITK_LIBRARY was not set for insight :-(
Try replacing the '&' by ';'.

Where should I insert it?

To check if it's the itk path problem:

$ wish
% package require itk

The answer is either "can't find package itk" (failure) or a dotted version number (success).
You can also try

$ wish
% package require Itk

(with uppercase I).
If both fail, this is the itk path bug

from insight.

Good news :)

  $ wish
  % package require Itk

printed the version number `3.3 while the former

  $ wish
  % package require itk

printed

  can't find package itk

So, it appears to be case issue, how can I use it to run insight ?

P.S.

  export ITK_LIBRARY=/usr/share/tcltk/itk3.3 ; insight 

fails again.

from insight.

Sorry for having been long: I was busy for my paid job.

Nevertheless, the fact that the itk package is found shows the bug is not the one I thought. Sorry.

I just installed a virtual machine with the ubuntu distro you mention and tried to compile and run insight. Full success, after having installed itcl3-dev, itk3-dev, iwidgets4, autogen, autoconf, automake, texinfo, lex, bison (and maybe some others I don't remember) manually with apt install. I have no multi-versions of the packages, nor things in /usr/local. I used --without-python for a quick test. There's no need to install InsightToolkit.

After successful compilation, I've been able to run insight directly from bundle/gdb/insight (without special environment settings) and load and step through a program to debug.

This proves your problem is definitively bound to a path inconsistency, dependent of your installation. I'm afraid I can't help more: you have to check compile logs to be sure the versions used at run-time match the ones used at compile time.

I suggest you restart from a clean installation of your OS, as I did for testing. This should work.

from insight.

I'm sorry for taking your time. It must be my Ubuntu installation, I use it since 13.04 version by dist-upgrading.
It compiled it successfully in my system but it fails to detect itk somehow. I must use a clean env. I ll use chroot.
I wish you all the best.

Thank you for all.
Kenn.

from insight.

You're welcome :-)
I wish you success with insight on your new install.
If you find something that can improve such tcl/tk detection in a reasonable way, please feel free to tell me.
Cheers,
Patrick

from insight.

Hello, I am having this same problem with Slackware 14.2, I have compiled itcl 3.4.1 and itk 3.4.1 both seem to have installed fine. The I run wish and use the package require Itk (with first character caps) and wish shows 3.4. But when I type package require itk it says can't find package itk. Which is what insight is also seeming to tell me. It will not start.

from insight.