Bug#430234: bug out of date
This bug only applies to old versions of Felix. Newer versions of Felix do not put any header files in /usr/include. Felix will build with whatever data types the C/C++ compiler provides by default. [Mike, this should be closed, it doesn't apply to the current version of Felix] -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, 2007-09-28 at 14:26 +0100, Richard Jones wrote: On Fri, Sep 28, 2007 at 03:17:27PM +0200, Stefano Zacchiroli wrote: On Fri, Sep 28, 2007 at 02:10:45PM +0100, Richard Jones wrote: In particular I could do it if INRIA said that they would support the change in some future release (see the exception Patches Heading Upstream). But otherwise this is quite a large ABI change -- if Fedora users started to build lots of 64 bit shared libraries linked with -lcamlrun I could end up maintaining it separately forever. [I meant to say -lcamlrun_shared here] I think you misunderstood my proposal. I don't want to apply your initial fix which changes libcamlrun.a into libcamlrun.so. I want to add a libcamlrun_shared.so, so there would be no ABI change, just the added possibility to link against it. Or maybe you're concerned about having to drop in the future support for libcamlrun_shared.so, but I think the user impact of that new library would be quite low. In fact I don't think anything else that mod_caml-like projects will need it ... That would also need to go upstream before Fedora could accept it. Why? I would have thought it is close to *policy* to provide libraries for both static and dynamic link. -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346572: [mipsel] Depends on ocaml-nox-3.08.3 which cannot be installed.
On Mon, 2006-01-09 at 00:37 +0100, Sven Luther wrote: qube:~# apt-get install ocaml Reading Package Lists... Done Building Dependency Tree... Done The following packages have unmet dependencies: ocaml: Depends: ocaml-nox-3.08.3 E: Broken packages I get this from my mirror regularly. It occurs because the package index is downloaded first .. but the packages come later. On Ubuntu I get a flashing thing telling me there are upgrades available .. only when I try to download them they're not there. An hour later .. they're there :) The mirror *should* add new packages, then add the index, then remove any hidden packages but I guess it just uses a generalised filesystem synching program. -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327736: lablgl: FTBFS on m68k, ocamlmktop crashes at exit
On Mon, 2005-09-12 at 11:35 +0200, Samuel Mimram wrote:
reassign 327736 tk8.4
thanks
tclsh return
load tk
Well, this does not work even on my i386 box:
% tclsh
% load tk
couldn't load file tk: tk: cannot open shared object file: No such
file or directory
Maybe the package path has to be set up correctly: I forget
how to do that .. hmm .. see below, looks like the correct
command is:
package require tk
So, I guess you meant load libtk8.4.so.
Technically, most tcl extensions should be
loaded by their tcl loader scripts, rather than in
the raw: the tk loader script exists, and is just
called 'tk' -- at least I think: haven't done any
tcl/tk programming for a while --
So you should NOT trust my comments, they're NOT authoritative,
just indicative of a possible problem.
[EMAIL PROTECTED]:~$ ls /usr/lib/tk8.4/tk.tcl
/usr/lib/tk8.4/tk.tcl
It says this:
# Initialization script normally executed in the interpreter for each
# Tk-based application. Arranges class bindings for widgets.
..
# Insist on running with compatible versions of Tcl and Tk.
package require -exact Tk 8.4
package require -exact Tcl 8.4
and there is this:
# Add Tk's directory to the end of the auto-load search path, if it
# isn't already on the path:
if {[info exists ::auto_path] [string compare {} $::tk_library] \
[lsearch -exact $::auto_path $::tk_library] 0} {
lappend ::auto_path $::tk_library
}
which suggests somehow /usr/lib/tk8.4 needed to be on the
auto-load search path already.
--
John Skaller skaller at users dot sourceforge dot net
signature.asc
Description: This is a digitally signed message part
Bug#327736: lablgl: FTBFS on m68k, ocamlmktop crashes at exit
no reason AT ALL to have a 'wish' program when you have dynamic linkage, except that the developers had no idea how to make dynamic linkage work (wish is needed if you only have static linkage). And this is almost certainly the problem with Ocaml's Tk bindings. Tk itself is linked incorrectly. 'It just works' on most systems by luck, and because executables export Tcl symbols which Tk needs. The *problem* is that to use the wrong linkage, Tk calls Tcl using weak symbols which are only linked when used .. or not .. which causes a segfault if they can't be found in the executable. If you try to do: dlopen(tcl) dlopen(tk) surprise suprise it doesn't work unless your executable is set up to propagate the symbols from tcl into the global symbol table so the subsequent load of Tk can find them. You have to use dlopen(tcl.so,RTLD_GLOBAL) to make it work. This is because Tk is not linked against tcl. It should be. However, Tk MUST NOT load Tcl... :) What's happening with the bug above? Well, Tk used to have an event loop, but Tcl did not. That got changed over time, so that these days Tk uses the Tcl event loop. Since Tk is meant to be loaded by Tcl -- even though Ousterhout could never figure out how to actually make it work -- it can also be *unloaded* -- its just another package. The problem is that the mainline is linking to Tk directly, and when it is unloaded the binary is creaming the event loop -- the plug is being pulled without Tcl knowing. The thing is, you are not ALLOWED to pull the plug on Tk. It MUST be done by Tcl, just as Tk MUST be loaded by Tcl, and NEVER by the application directly. Tk C API MUST NOT ever be called by any applications!!! The Tk API is ONLY available to dynamically loadable widgets loaded BY Tk. The reason, trivially, is that there is no correct way for an application to load Tk, except via Tcl script, because it is Tcl that MUST load Tk, not the other way around -- which means the application cannot see the Tk API because it isn't allowed to dlopen() it -- well, at least not until AFTER Tcl has already done so!! What's happening? The destructors for Tk's static data -- Tk is a brain dead piece of code, it isn't reentrant -- are operating on data that is ALREADY unmapped. There is a pointer in there pointing to Tcl data. But Tcl is already gone. Because Tk was Kludged to load Tcl to make thousands of wrong programs work, because Ousterhout got it all wrong in the first place. Solution: dlopen() Tcl BEFORE linking to Tk. That way, Tcl won't be unloaded prematurely. The best way to do that is to dlopen() Tcl first, initialise it, then TELL Tcl to load Tk. After that you can dlopen Tk .. when you dlclose it, it will not be destroyed because Tcl is still using it. Tcl will release it when IT is destroyed. It is important that the client has already dlclosed it at this point. Hope this rant all makes sense. Bottom line is that Tk has been misused by everyone for decades including its designer, who never understood how to make it load properly -- so it isn't surprising no one else did either. Looks like it is STILL all wrong. The open chain MUST go: appl -- tcl -- tk and the close chain is the reverse. If the app wants to call Tk api, it can open tk after Tcl has. It should close it before closing Tcl, so that Tcl can close tk, which allows tk to unlink itself from the event loop whilst that event loop's static data is still held by Tcl. -- John Skaller skaller at users dot sourceforge dot net signature.asc Description: This is a digitally signed message part
