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.
Related
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.
I am on Mac OSX 10.7 however I believe this would also appear in 10.8+
Try running (within erlang)
wx:demo().
Which will produce the following output:
beam.smp[2733:f0b] CFURLCreateWithString was passed this invalid URL string: '/System/Library/CoreServices/CommonCocoaPanels.bundle' (a file system path instead of an URL string). The URL created will not work with most file URL functions. CFURLCreateWithFileSystemPath or CFURLCreateWithFileSystemPathRelativeToBase should be used instead.
Now the demo runs just fine but why output this line then?
It speaks nothing of erlang and after some browsing around it seems as if this is a wxWidgets bug as people have the same issue in python and that it is Mac OSX centric due to the CommonCocoaPanels.bundle in the output.
Its really just an annoyance for now as everything runs just fine. But it is more than likely a bug, no?
How can it be fixed?
As far as I know wxErlang is currently broken on MacOS and maintainers promise to fix it after wxWidgets 3.0 release.
Which version of wxWidgets are you using? I used wxWidgets 2.8.12 under Mac OS 10.6.8, custom build for Carbon with -arch i386.
In wxWidgets 2.8.x, Carbon is the recommended library because it is the
more stable. Cocoa is incomplete in wxWidgets 2.8.x. If you are interested
in using Cocoa, you should start with wxWidgets 2.9.x where Cocoa is
much more complete.
The framework itself looked somehow alien to Max OS (maybe because of Carbon), a small part of API was broken (this does not prevent programs to actually run - just small annoyances).
For my future reference, and that of others..
The following will work without displaying the above error message.
P = wx:new(),
F = wxFrame:new(P, 1, "main", [{size, {600,600}]),
WindowOpts = [{size, {600,600}}, {style, ?wxSUNKEN_BORDER}],
W = wxWindow:new(F, ?wxID_ANY, WindowOpts),
wxFrame:connect(F, close_window, [{skip,true}]),
wxWindow:connect(W, paint, [{skip, true}]),
wxFrame:show(F),
wxFrame:centre(F).
Strangely enough even with all my trial and error debugging, line by line, there is really no easy way to get to the bottom of it. It turns out to be the inclusion of a:
process_flag(trap_errors, true)
Will generate that error. I am positive there is nothing crashing that would invoke the actions of the flag.
Deep error. Little consequence.
Lets hope they get it fixed along with the 3.0 upgrade.
I've written some application code using JMF, but would like to switch to FMJ to make delivery easier.
Unfortunately, on my Windows 7 laptop (where JMF works fine once installed), I downloaded fmj-20070928-0938.zip, uncompressed it, and ran fmjstudio.bat. As soon as I click on the webcam icon, I get errors which start with "WARNING: com.lti.civil.CaptureException: java.lang.UnsatisfiedLinkError: C:\Temp\fmj-extracted\native\win32-x86\civil.dll: Can't find dependent libraries"
Any suggestions?
Although it is probably not a complete answer, a partial answer is that FMJ uses 32-bit libraries. I am fairly sure I was using a 64-bit java.
On a different Windows 7 computer I successfully got fmjstudio to run using a 32-bit java. Next step is getting it to recognize the camera for my own app rather than fmjstudio.
A while back I was following some tutorials an assembly. I was running it all on a windows machine, compiling with NASM and then writing the compiled code to a floppy disk, then reboot and try the code. This process was long and time consuming and sadly was not on a mac. When I found out that Xcode for mac installed NASM I immediately tried to compile some code. The code compiled fine. The issue is testing it. On a mac I have no floppy (not like I want to use one) so Im not sure how to test this. I looked in to Q (kju) and found it would only emulate things on an ISO file. So I guess what Im asking is is it possible to install the compiled code on an ISO file for testing? (Note: the code when compiled forms a .bin file)
Thanks for any help
I don't know exactly what you are trying to test (a boot loader maybe?) but you don't need to reboot or boot from a disk just to run assembled code (unless it is a boot loader or something).
Either way, if you need to "reboot" to test, I suggest running an emulator. Sun VirtualBox is super easy to use and free and emulates a standard x86 architecture (including floppy drives)! So that may work for you in the short term. If you ever want to create an ISO image in the future, you can do that with the command line utility hdiutil. In a terminal window, type man hdiutil or visit the online man page for more information on using that to create all kinds of disk images.
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.