I'm trying to setup the files from LuaBinaries (specifically Lua 5.2.4 64-bit), and there are a few things I'm confused about.
There are two zip files provided, the binaries: lua-*_Win*_bin.zip and the libraries: lua-*_Win*_*_lib.zip
So, these are my questions:
For the libraries, two versions are provided, static and dynamic. What's the difference?
The zip file for the dynamic libraries contains a lua*.dll, but a file with the same name is provided in the zip file for the binaries. Which one should I use?
Some of the library zip files (the older ones?) contains a liblua*.a file, is this supposed to be a misnamed lua*.lib file?
For the libraries, two versions are provided, static and dynamic. What's the difference?
The static library can be embedded into your own program. While the dynamic library is linked to your program, so the system will search for it when running your program. If the search for the dynamic library failed, the system won't be able to run your program correctly.
The zip file for the dynamic libraries contains a lua*.dll, but a file with the same name is provided in the zip file for the binaries. Which one should I use?
The lua*.dll under lua-*_Win*_bin.zip is the dynamic link library(.dll) used by lua.exe and luac.exe. An error will be thrown by Windows if you run lua.exe after deleting it.
Which one should you use? It depends on your purpose. Usually you want to use the static library in you project.
Running different versions of Lua bytecode (e.g., runs the bytecode created by luac v5.1.4 with lua v5.2.4) is forbidden (by checking the header of bytecode files).
Lua sometimes brings breaking changes upon upgrading, and some public APIs vary between different versions. If you build and install Lua from source code, only the binaries and the static library are produced.
Lua is a very tiny language (the static library under Linux is about 356K(v5.1.4) or 440K(v5.3.3), measured by du -sh liblua.a), so embedding the static library with your program is fine for many high-end devices.
If you feel familiar with make command, you can build Lua from source code and load it into your project. Or, just use the static library in your project. (I don't think most Windows users have a lua*.dll in their enviroment.)
Some of the library zip files (the older ones?) contains a liblua*.a file, is this supposed to be a misnamed lua*.lib file?
No, the libxxx.a and libxxx.so is the static and dynamic library naming conventions under *nix systems, like Linux and FreeBSD.
Related
I installed boost using brew install boost in order to use odeint library (the odeint webpage says : odeint is a header-only library, no linking against pre-compiled code is required).
I am on Mac Yosemite 10.10.5 . Now when I cd to /usr/local/include, I can see boost directory there. Inside boost (/usr/local/include/boost) there are all the header files I needed for my project, along with the numeric/odeint directories needed for my specific purposes. At the same time, when I cd to usr\local\lib, I can see a lot of libboost_* .dylib and .a files.
However, when I try to compile a c++ file that I temporarily save in ~/Downloads (the first header is #include <boost/array.hpp>), I got the error fatal error: 'boost/array.hpp' file not found.
I am inexperienced in programming, and I really appreciate your help! Thank you!
Use the following include statements and let us know if it works.
#include <boost/numeric/odeint.hpp>
#include <boost/numeric/ublas/matrix.hpp>
If not, some additional info is needed. What is your BOOST version, what is the structure of the /usr/local/include/boost directory, how about including other (non-boost) headers from /usr/local/include (maybe compiler include path is broken).
I asked my professor about this. He gave very detailed explanation, and I think I should share so that everyone can benefit from it:
Theory:
Your compiler needs to know where these files are. You need to find a way to tell it where the files are.
Depending on how you are doing the compiling there will be different solutions. If you are compiling via the command line, use something like
g++ -I/usr/local/Cellar/boost
The -I stands for "include files". There is a similar g++ "switch" called -L for libraries when you get to that stage.
There is also a whole series of tools to tell the compiler how to search for include files. The directory /usr/local/include is almost certainly on the list of places for it to look.
If you are using "make" and the associated tools for compiling, you can add the include directories to part of the "Makefile". Again, the details are different for every setting.
Bottom line -- you'll need to learn more about your compiler system. Find manuals and examples for your specific tools and system. Learn how those tools work and where to specify the boost libraries. Read the boost manuals and learn where they store files and what all the names are for the different directories where these files are stored.
It's not fun work, but it is worthwhile learning about how all the parts get put together.
I was following a tutorial for object detection using opencv, I did it step by step but when I run it, I got this error -
The program can't start because opencv_244d.dll is missing from your computer.
Try reinstalling the program to fix this problem.
I don't know what is the problem because I can see this dll in opencv libraries, I have added the following to the input dependencies:
opencv_core244d.lib
opencv_imgproc244d.lib
opencv_highgui244d.lib
opencv_ml244d.lib
opencv_video244d.lib
opencv_features2d244d.lib
opencv_calib3d244d.lib
opencv_objdetect244d.lib
opencv_contrib244d.lib
opencv_legacy244d.lib
opencv_flann244d.lib
This is still not working, what can I do?
You can find the required dll files into the bin folder (that is next to lib folder where the .lib files are located), and you have two options:
1) copy the required dlls into the same folder with your application //this is a little better because it kind of prepares you for when you'll need to deploy your application on systems that don't have opencv installed (for then don't forget to build the release version of your application)
or
2) add to the Path in the Environment Variables your path to that bin folder (be carefull that the path in there are separated by ; )
I would advise you to build the OpenCV libraries from source so that you can have a custom installation specific for your system (this is always better since it gives you the option of using what you want/need and also the performance is better since the libs are custom-made for your system).
OpenCV does not contain a library file called "opencv_244d.dll".
Check all your dependencies and their names so you don't have any misspelled names. All the names are something like "opencv_name244d.dll" such as "opencv_photo244d.dll".
I am developing a lua library for Corona which contains code spread across files. I am using luac to generate a single bytecode file which I can share with other developers so that they can use my library easily and without looking at code. Problem is that I am getting "bad header in precompiled chunk" error. From searching around, I find that its because I need to compile for ARM.
What would be right approach for me here?
Lua bytecode is not portable neither across version, nor across platforms; see luac docs.
Update
If you are just trying to pack some files together you could see Squish.
If you need a real deploying system for Lua there is Luarocks.
I am working in a very large iOS project and it has so many classes and resources that it takes very long time to index and compile them. As it still grows more and more, I need to do something about this because I am spending too much of my time waiting for the IDE to let me work.
My first idea was to pack all the images in a custom bundle so the IDE will see it as a single file and would be faster to index and copy it, but I have seen that a bundle is nothing more than a simple folder with an extension, so I guess that the performance would still be slow. Then I read that if I used "blue folders" instead of "yellow groups" for my images, Xcode would not index them. But this way is not easy right now, as I should replace my function that looks for images to look for them in that folder (absolute paths?)
So my last approach will be saving time in both compile time and indexing. I want to modularize my code in multiple libraries so it will not be necessary to compile it "ever" again and this way Xcode won't need to index the source files neither.
I have followed some tutorials and now I know how to create a static library and include the header files in another project. But my current problem is as follows.
My application has several "independent" modules, so I want to create a static library for each one (and maybe I'll generate an image bundle for each one too...). But all of those modules use a common core, which I'd like to maintain in a static library too. So, if I do it like this, I will have to include the main core library in every module library, and I'm afraid this will not be the most optimum way, as the binary code of the core will be there several times, right?
I guess the correct solution would be to generate a dynamic library for the core and static ones for the modules, but I can't find how to generate the dynamic one... Furthermore, I'm not sure this would be the solution.
So I ask you: what options do I have? Is compiling the core several times the best approach I have?
Thank you so much for your help!
Dynamic linking is not supported in IOS, so this isn't an option. While the static libraries are added to the other libraries, it isn't embedded inside the other static library, you can see this when you do a build, the other libraries should show as a separate libraries inside the project folder, hence each static library/project will only get included once in the app build.
In the end ... I am not sure this will save you a lot of time you are expecting if you are using static libraries in the same workspace. I use static libraries in some projects and if I do a Clean on the app, then a build, the static library will get re-built also.
Has anyone used Bluetooth on Mac OS X with Lazarus or FreePascal? There is a bluetooth unit, but it currently only supports Linux.
Information about existing unit:
http://wiki.freepascal.org/Bluetooth
I plan to enhance this to support Mac OS, but it would be nice to know if anyone has written any code to use BlueTooth on Mac OS already to avoid duplicated work.
On the other hand, if you have used XCode to access Bluetooth, what libraries did you use? I am sure I can discover this with the XCode profiler by opening some Bluetooth applications.
Note: Mac OS X doesn't appear to use the BlueZ library that Linux has, so I don't think the solution is as easy as changing the library path. Instead, it has IOBluetooth "Framework", located at /System/Library/Frameworks/IOBluetooth.framework.
Having a look, it looks like:
kaikei.ocn.ntt.com:IOBluetooth.framework $ file *
CodeResources: XML document text
Headers: directory
IOBluetooth: Mach-O universal binary with 3 architectures
IOBluetooth (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
IOBluetooth (for architecture i386): Mach-O dynamically linked shared library i386
IOBluetooth (for architecture ppc7400): Mach-O dynamically linked shared library ppc
Resources: directory
Versions: directory
On the other hand, I think if anyone had done this already, I would probably be able to find it on Google.... On the off chance I am wrong, please reply and let me know.
Clarification: I have created bindings for normal shared libraries before (f.e. sqlite3), but not for a "framework". If nobody has created bindings or otherwise used the MacOS Bluetooth framework from FreePascal, advice on how to use framework functions from FreePascal in general woule be appreciated. (And normally the functions I am porting are C based, not Obj-C, so I am not sure how to declare Obj-C methods in FPK, although I am sure I will be able to find some samples if I keep searching).
The main svn repository for translated Mac OS X framework C headers is http://svn.freepascal.org/svn/macosxintf/trunk
From time to time, FPC releases are synchronised with the latest versions hosted there. Note that the files in that repository (in the MPPInterfaces subdirectory) are in a generic format that can be automatically translated into either FPC, GPC or CodeWarrior Pascal versions.
To generate the FPC versions, use "make fpcpinterfaces", and find the results in the Build/FPCPinterfaces folder.
To translate new headers, execute something like this from inside a checked out copy of the macosxintf repository:
./Scripts/Convert.pl /System/Library/Frameworks/IOBluetooth.framework/Headers/IOBluetooth.h FORCE MPPInterfaces
Afterwards, you'll still have to edit the resulting file to add/remove units and clean up some other things not handled by the automatic translation process. Once finished, you may want to submit a bug report at bugs.freepascal.org with the finished units.
(note: because I'm unregistered, I can only add in one url per post, so the next url's are a bit mangled to get around that restriction)
You can also subscribe to the Mac Pascal list (lists.sonic.net/mailman/listinfo/mac-pascal) and ask there whether someone already translated those headers.
The Bluetooth framework indeed also contains some Objective-C headers. Objective-Pascal support is only available in the latest FPC svn versions, as described on the FPC wiki (google FPC_PasCocoa). You need this support in order to interface with Objective-C.
Translating Objective-C is probably easiest using the script elsewhere in FPC's svn (svn.freepascal.org/svn/fpc/trunk/packages/cocoaint/utils/)
You may want to ask for help on the above-mentioned Mac Pascal list, as all people maintaining the aforementioned translations and translation tools are subscribed there.