The tcl-8.5.7 tclPort.h ends up asking for #include "tclUnixPort.h" but that needs to be #include "../unix/tclUnixPort.h" or (for example) otcl cannot build against it. See the 8.4 installation for reference. Actually, there seem to be other problems building against tcl-8.5.7, at least for me it is difficult to get otcl to rebuild.
Ooops. I checked for tcl-8.5.7 problems but did not realize this was an otcl problem. :( *** This bug has been marked as a duplicate of bug 213028 ***
otcl is dead. there is xotcl though. long live to xotcl!
(In reply to comment #2) > otcl is dead. > there is xotcl though. > long live to xotcl! > Problem is that 2 packages DEPEND on otcl: tclcl and net-analyzer/ns (which most certainly is not dead). I syspect that ns is the only package which cares about either of these (or so suggests equery. ns (network simulator) is a very old package, but it has an extremely active user base.
(In reply to comment #3) > (In reply to comment #2) > > otcl is dead. > > there is xotcl though. > > long live to xotcl! > > > Problem is that 2 packages DEPEND on otcl: tclcl and net-analyzer/ns (which > most certainly is not dead). I syspect that ns is the only package which cares > about either of these (or so suggests equery. ns (network simulator) is a very > old package, but it has an extremely active user base. > And of course there is no package for xotcl. :)
I'm aware there are a couple of pkgs depending on otcl. But what can I do? The world can't stop because of an obsolete package. Does the upstream (of ns I mean) know that otcl is dead and is incompatible with tcl-8.5? What I see for the future is dropping otcl and its rrdeps... :( Any better solution?
(In reply to comment #5) > I'm aware there are a couple of pkgs depending on otcl. > But what can I do? > The world can't stop because of an obsolete package. > Does the upstream (of ns I mean) know that otcl is dead and is incompatible > with tcl-8.5? I don't know. I'll try to find out. > What I see for the future is dropping otcl and its rrdeps... :( > Any better solution? > Not off hand. But as I mentioned, ns is a major package (don't know how much it gets on gentoo, though.)
