I am trying to use a Tcl application called "Linger" (developed by Doug Rohde) in order to create a reading experiment. I need to use the package Snack in order to record subjects' repetitions of what they read. I got a number of error messages when trying the script in the application, all related to this package.
So, in Wish I tried to find out whether the package is correctly loaded.
package require snack
yields
couldn't load library "C:/Tcl/lib/tcl8.6/snack2.2/libsnack.dll"
When first running
package provide snack 2.2.10
then
package require snack
it gives me
2.2.10
Does that mean the package is loaded?
I tried to solve this question by running one of the basic commands in Snack's tutorial.
snack::sound s
should create a Snack sound object named s; when I try it, however, Wish gives me
invalid command name "snack::sound"
So now I know why my Linger script doesn't work, but I don't know how to solve the problem. I am very grateful for help or anyone pointing out a link with the answer.
I am running Tcl/Tk 8.6.3 and snack 2.2.10 on Windows 7 (64-bit). Tried the same on Mac OS 10.6 and Linux; same result.
The problem is that the implementation of the package is not being loaded for some reason. Alas, the error diagnostic:
couldn't load library "C:/Tcl/lib/tcl8.6/snack2.2/libsnack.dll"
isn't especially informative. If the file C:\Tcl\lib\tcl8.6\snack2.2\libsnack.dll exists (which you can check in Explorer; Tcl prefers to use Unix-style directory name separators internally) then it's most likely to be a 32-bit library vs 64-bit application (or vice versa) issue; you can't load mismatched libraries into running applications under anything remotely approaching normal circumstances.
Unfortunately, it seems that Snack is one of the packages that is most likely to be absent in a Tcl installation (it's not part of the ActiveTcl distribution, for example). You could try getting the code from the Snack site but I think that likely will need a 32-bit build of Tcl/Tk to work, and we now default to 64-bit builds on most platforms. I don't know why Snack stopped being built as part of ActiveTcl.
Doing a
package provide snack 2.2.10
won't help you. It just tells a lie to the Tcl runtime about the package, but without the real implementation, you won't be able to use it. (Strictly, it's how a package implementation tells the package manager that it has successfully loaded. It should only be used by package implementations under normal circumstances.)
If you will download and install WinTclTk snack will work. WinTclTk has snack already included. So you don't have to install it manualy. Just type
package require snack
and you will get information about already included snack package.
I tried it on virtual Windows XP(32bit).
I was trying the snack software from snack original site on Windows 7(64bit) and Ubuntu(64bit) with no success.
Related
I need a debug version of glibc.I have some doubts regarding the installation of glibc-2.29 from source in kali linux.Based on the post https://www.tldp.org/HOWTO/html_single/Glibc-Install-HOWTO/,
To install glibc you need a system with nothing running on it, since many processes (for example sendmail) always try to use the library and therefore block the files from being replaced. Therefore we need a "naked" system, running nothing except the things we absolutely need. You can achieve this by passing the boot option
init=/bin/bash to your kernel.
it says that we need to install the glibc in a single usermode environment.In another post https://www.tldp.org/HOWTO/Glibc2-HOWTO-5.html
single usermode is not required for installation but backing up the old libraries.I dont know which one to follow.Can anyone help?
I found that we can use glibc without installing but building from source by adding '-g' flag in ./configure and setting LD_LIBRARY_PATH varible as follows after building
LD_LIBRARY_PATH=/path/to/the/build_directory gdb -q application
Note: this solution only works when the system GLIBC and the built-from-source GLIBC exactly match, as explained here.
I need a debug version of glibc.
Most distributions supply ready-made libc6-dbg packages that match your installed GLIBC. This is the best approach unless you are a GLIBC developer (or plan to become one).
I have some doubts regarding the installation of glibc-2.29 from source in kali linux.
Installing / replacing system libc is almost guaranteed to render your system unbootable if there are any mistakes. Recent example.
Before you begin, make sure you either know how to recover from such a mistake (have a rescue disk ready and know how to use it), or you have nothing of value on the system and can re-image it from installation media in the likely case that you do make a mistake.
The document you referenced talks about upgrading from libc5 to libc6. It was last updated on 22 June 1998, and is more than 20 years old. I suggest you find some more recent sources. Current documentation does suggest doing make install while in single-user mode.
I use gopacket in my program. on linux, it runs perfectly.
But on windows the whole program crashes if i did not install WinPcap before.
My plan was to check if WinPcap is installed, and if not to inform the user that he needs this to use 100% of all features.
But i dont come to this point. i cant use gopacket if WinPcap is not available. I mean... not a single line of code of it (=> crash)
Has anyone an idea how i can solve this? im do not need gopacket actually. My plan was, if it is installed, fine, super! If not, dont care... do other things.
But now i have 2 choices... remove gopacket totally or find a way to start my program without the need of wpcap.dll. at least to tell the user that he needs it.
Please help me :(
You're wrong in that you are «not [using] a single line of code of it»: it's not hard to see that
its Windows-specific code calls into winpcap.dll.
What is more fun, is that
its Unix-specific code calls into libpcap.so, and this means you have it working on your local system simply due to the fact you have libpcap package installed (or whatever it's named in your code).
All this means that currently your program is not really portable
anyway (I mean, in the sense you supposedly think it is portable).
You can run something like
$ ldd ./yourbinary
and see it printing a reference to libpcap.so of some version.
There are several ways to solve this.
The easiest is to just try shipping winpcap.dll with your binary. Windows by default looks for DLLs in the current directory of the application trying to load them. Since gopacket uses cgo, it means the winpcap.dll is attempted to be linked it at the application startup, so the application has no chance of changing its working directory before that library is attempted to be found and linked in.
A more complicated approach is to make (or obtain) a static version of the winpcap library (remember that DLL is a library, just a special form of it) and then jump around building gopacket so that it picks that static library.
Install Npcap in "Wpcap API compatibility mode".
I'm currently trying to achieve (for my internship) to use Mac OS dll which are named Bundle (everthing is named bundle on mac ...) because the string comparison fonction from Wine is not working properly (gérard = gerard for example). It causes problems on databases because of the duplications.
Using a DLL to use the native comparison fonction of the OS would settle this problem. But unfortunately, there aren't a lot of documentations to implement properly a working Bundle DLL.
Until now (with my tutor), we succeeded to create a ".bundle" (which works perfectly fine) and then a ".so" but when using it under Wine, we got this error "Bad EXE Format for %1" which tell us that our dll is not in the right format because Wine need a spec file to use native DLL.
We found documentations to make a spec file on WineHQ website but we can't overcome this phase by just following the instructions here(click sur "next" to have the following steps in the bottom right corner ...).
Has anyone ever succeeded (the only one person I saw do it, did it in 2005 ...) to use mac OS DLL on wine and could help us ?
Any help most appreciated.
I'm fairly experienced in Python, but a total noob on OSX. I've been using it for a couple of years on windoze then linux OK. Unfortunately I now need to port stuff to an iMac with El Capitain 10.11.3.
I checked out the guides before I tried to install it, in particular the issues around the versions of the tk/tcl libraries. I therefore visited ActiveState, and installed the latest version, then python 3.5.1. This is something that I have never done with 'doze or 'nux.
Simple text programs run OK, whether from IDLE/run, python3 progname, or shebang. The following simple tki program also runs OK, also from those three launch methods.
#! /Library/Frameworks/Python.framework/Versions/3.5/bin/python3
import tkinter as tki
def cmd():
print('doing command')
exit()
root = tki.Tk()
but = tki.Button(root, text='hello', command=cmd)
but.grid()
root.mainloop()
But when I try to run a sizeable tki based app, it complains that it has found classes TKApplication, TKMenu, TKContentView and TKWindow in both /Library/Frameworks/... which is where python is installed, and /System/Library/Frameworks/... which is presumably where the tcl/tk install from ActiveState went. It then exits with a segfault 11. The app is basically low level tk stuff, just a lot of it. Both locations include /Versions/8.5/ in the name.
I suspect the key is that it says which one of each of those TKxx will be used is undefined. Perhaps it's picking a mix of those, and so when they go to talk to each other, they are not in predictable locations.
Is this what's happening? Why does the simple tk app work but not the complex one, is it the size, or the need to use several classes from different libraries?
As there seems to be a set of tk libraries in the python tree, I'm inclined to remove the ActiveState ones. Is this sensible? How do I do this (Mac noob alert)!
I don't seem to be able to find a definitive 'how to' install python 3 on OSX. Not found too much specifically for 10.11.3, could this OSX version need a different procedure?
I really hope someone can be of help to me because this problem has me totally stuck and frustrated.
Yesterday I installed a fresh and shiney new Windows 7 x64 onto a development box.
I got VS2008 installed, Tortoise SVN, did a checkout, compiled my currently project, all fine and dandy.
But when I go to run (either F5 in VS or just running the exe from the shell) I get a dialog box that looks like this:
(source: aliparr.net)
So I fiddle around and can't see an obvious problem. I bust out depends.exe, thinking maybe there's a dll missing, and I get this:
(source: aliparr.net)
So I play, finding different versions of gpsvc.dll and ishims.dll and putting them in with the .exe, No luck.
If I do a profile in depends (which follows the Output window of vs), I get this:
..
Loaded "c:\windows\syswow64\ADVAPI32.DLL" at address 0x75F20000 by thread 1. Successfully hooked module.
Loaded "c:\windows\syswow64\LPK.DLL" at address 0x76B20000 by thread 1. Successfully hooked module.
Loaded "c:\windows\syswow64\USP10.DLL" at address 0x761C0000 by thread 1. Successfully hooked module.
Loaded "c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_508ed732bcbc0e5a\MSVCR90.DLL" at address 0x70570000 by thread 1. Successfully hooked module.
Loaded "c:\users\ali\desktop\repository\development\trunk\spree\bin\debug\OPENLDAP.DLL" at address 0x001E0000 by thread 1. Successfully hooked module.
Exited "c:\users\ali\desktop\repository\development\trunk\spree\bin\debug\SPREE.EXE" (process 0x5D4) with code -1073741701 (0xC000007B) by thread 1.
So it seems openldap.dll is the last thing to get loaded before it all goes wrong. I require this dll because I use cURL within the application to do a little JSON communicating...
I've tried playing with moving files and trying differing dlls, but honestly I'm acting a little blind here. Can someone please help or point me in the right direction?
It should be noted these dlls and setup work fine in Windows Vista x64 and x86 - is this a Windows 7 thing?
Massive thanks in advance, I might still have some hair left after this is done.
Edit
I've now realised curl.exe dies in exactly the same way with openldap.dll - I guess some windows 7 issue?
Can you/does anyone have a curl without the dependency on openldap? Is there another lightweight C/C++ library out there that'll let me fetch a document over http and do the odd http POST ?
Thanks
I had a very similar problem myself: I was developing a C program (using the MinGW gcc compiler) which used the curl library to do http GET operations. I tested it on Windows XP (32-bit) and Windows 7 (64-bit). My program was working in Windows XP, but in Windows 7 it crashed with the same 0xc000007b error message as the OP got.
I used Dependency Walker on a down-stripped program (with only one call to the curl library:curl_easy_init()). I essentially got the same log as yours, with OPENLDAP.DLL as the last successfully loaded module before the crash.
However, it seems my program crashed upon loading LIBSASL.DLL (which was the next module loaded according to the log from Dependency Walker run on Windows XP).
When looking again in the log from Dependency Walker on Windows 7, LIBSASL.DLL indeed shows up a x64 module. I managed to get my program to run by copying a 32-bit version of the DLL file from another application on my harddisk to my program's directory.
Hopefully this will work for other people having similar problems (also for the OP if the problem still wasn't resolved after these years). If copying a 32-bit version of LIBSADL.DLL to your program's directory doesn't help, another module might cause the crash. Run Dependency Walker on both the 32- and 64-bit systems and look up the module name from the log of the successful run.
I cannot answer your questions completely, I've compiled libcurl on Windows 7 Professional x64 and I don't have any issues. Although I haven't compiled it with OpenLDAP support so I suppose that's where the issue lies.
Regarding the IEShims.dll, Dependency Walker usually reports this as a missing module. Can't remember the exact reason but it was something about loading it dynamically when it's not found in %Path%.
If you however need to debug this and are on Windows 7 then try doing a hard link from %ProgramFiles%\Internet Explorer\IEShims.dll to %windir%.
Although, I see on the screen dump that it sure looks like Spree.exe isn't loaded as a x64 binary, which could very well be it. There's a difference in loading exported functions and piping or exec() a binary, the first mentioned requires that the architecture is the same for both the importer and exporter.
I've also found that mine is trying to load a 64 bit version of LIBSASL.DLL - the one that came with my 64 bit Tortoise distribution. I also only need curl for pulling a bit of JSON data. I think the best solution is going to be to rebuild libcurl from source and exclude the LDAP since I don't need it anyway.
Similar issue here. DLL dependents GPSVC.DLL and MSVCR90.DLL.
I managed to get rid of IESHIMS.dll by setting my environment variables path to C:\Program Files (x86)\Internet Explorer. Surely that shouldn't need to be done!
Is there a fix to this yet?
libsasl requires ieshims.dll, if you don't have sasl support in openldap, then ieshims.dll won't be required.
If you use windows x64 you have to copy your dll to c:/windows/SysWoW64. I have had the same problem when i wanted use pthreads in windows os 8. When I was copied pthreads dll to SysWow64 the program was run sucessfully.