I've been searching for a solution to do this for a while now, but still unsure. How do u install the PDCurses library in cygwin. I have the zip, I just don't know where to place the files. Is there a way to do this?
Thanks in advance
EDIT: If ncurses itself would be better how would I go about installing that with cygwin. Whichever one works. Basically how would I get ncurses like functionality in windows.
I hate doing this but I solved it and wanted to get the answer out there. Download the files http://pdcurses.sourceforge.net/ at this location. A more direct link is http://sourceforge.net/projects/pdcurses/files/pdcurses/3.4/. I downloaded this one "pdc34dllw.zip". Place all files in the same location as the file you are compiling.
you must link the lib to your file like this
gcc ./your_file_name ./pdcurses.lib
and your done. I think the *.dll needs to stay with the file though so include that when you distribute.
Make sure you include the file curses.h in your file. #include "curses.h"
It seems to work with all the classic ncurses commands :-)
Related
My main goal is that I want to understand how parameters works in ./configure. So, I decided to install ncurses and vim in $HOME/local/, so, as to not affect my system.
while configuring vim, I looked into --with-local-dir and includedir. I want to know what is the difference between them.
When I looked into vim-git-INSTALL-script, it said:
Unix: LOCAL HEADERS AND LIBRARIES NOT IN /usr/local
Sometimes it is necessary to search different path than /usr/local for locally
installed headers (/usr/local/include) and libraries (/usr/local/lib).
To search /stranger/include and /stranger/lib for locally installed
headers and libraries, use:
./configure --with-local-dir=/stranger
I thought that was the purpose of includedir. I would appreciate if someone can tell me where I went wrong. Thank you!
Conventionally (and per documentation), includedir is used for the directory where the current program would install header files. That's not the same as the places where the configure script might have to tell the compiler to find the header files needed to compile the program.
I have an application that relies on Qt, GDCM, and VTK, with the main build environment being Qt. All of these libraries are cross-platform and compile on Windows, Mac, and Linux. I need to deploy the application to Linux after deploying on Windows. The versions of vtk and gdcm I'm using are trunk versions from git (about a month old), more recent than what I can get apt-get on Ubuntu 11.04, which is my current (and only) Linux deployment target.
What is the accepted method for deploying an application that relies on these kinds of libraries?
Should I be statically linking here, to avoid LD_LIBRARY_PATH? I see conflicting reports on LD_LIBRARY_PATH; tutorials like this one suggest that it's the 'right way' to modify the library path to use shared libraries through system reboots. Others suggest that I should never set LD_LIBRARY_PATH. In the default version of GDCM, the installation already puts libraries into the /usr/local/lib directory, so those libraries get seen when I run ldd <my program>. VTK, on the other hand, puts its libraries into /usr/local/lib/vtk-5.9, which is not part of the LD_LIBRARY_PATH on most user's machines, and so is not found unless some change is made to the system. Copying the VTK files into '/usr/local/lib' does not allow 'ldd' to see the files.
So, how can I make my application see VTK to use the libraries?
On windows, deploying the dlls is very straightforward, because I can just include them in the installer, and the application finds them because they are in the local directory. That approach does not work in Linux, so I was going to have the users install Qt, GDCM, and VTK from whatever appropriate source and use the default locations, and then have the application point to those default locations. However, since VTK is putting things into a non-standard location, should I also expect users to modify LD_LIBRARY_PATH? Should I include the specific versions of the libraries that I want and then figure out how to make the executable look in the local directory for those libraries and ignore the ones it finds in the library path?
Every "serious" commercial application I have ever seen uses LD_LIBRARY_PATH. They invariably include a shell script that looks something like this:
#!/bin/sh
here="${0%/*}" # or you can use `dirname "$0"`
LD_LIBRARY_PATH="$here"/lib:"$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH
exec "$0".bin "$#"
They name this script something like .wrapper and create a directory tree that looks like this:
.wrapper
lib/ (directory full of .so files)
app1 -> .wrapper (symlink)
app1.bin (executable)
app2 -> .wrapper (symlink)
app2.bin (executable)
Now you can copy this whole tree to wherever you want, and you can run "/path/to/tree/app1" or "/path/to/tree/app2 --with --some --arguments" and it will work. So will putting /path/to/tree in your PATH.
Incidentally, this is also how Firefox and Chrome do it, more or less.
Whoever told you not to use LD_LIBRARY_PATH is full of it, IMHO.
Which system libraries you want to put in lib depends on which Linux versions you want to officially support.
Do not even think about static linking. The glibc developers do not like it, they do not care about supporting it, and they somehow manage to break it a little harder with every release.
Good luck.
In general, you're best off depending on the 'normal' versions of the libraries for whatever distribution you're targetting (and saying you don't support dists that don't support recent enough versions of the lib), but if you REALLY need to depend on a bleeding edge version of some shared lib, you can link your app with -Wl,-rpath,'$ORIGIN' and then install a copy of the exact version you want in the same directory as your executable.
Note that if you use make, you'll need $$ in the makefile to get a single $ into the argument that is actually sent to the linker. The single qutoes are needed so the shell doesn't munge things...
Well, there are two options for deploying Linux application.
The correct way:
make a package for your app and for the libraries, if they are so special, that they can't be installed from standard repositories
There are two major package formats. RPM and DEB.
The easy way:
make a self-extract file that will install the "windows way" into /opt.
You can have libraries in the same directory as the executable, it's just not the preferred way.
I´m doin a unattended cygwin installation and I was wondering if there will occure any problems without a setup.ini.
Following: my "install-folder" includes a setup.exe and a subfolder release (within all the packages packed).
I´m starting the setup silent (with Nsis) and install the packages. In NSIS I define the Root, the location of the packages etc.
I think it works so far (I´m not sure because i´ve got a curious error in cmake). There are many instructions how to modify the whole setup for an offline installation. But I don´t get the point why I have to modify it at all.
I hope anyone has got experience with this issue!
#Daniel Le cygwin installs the packages without the .ini (all of them). And there has nothing to be downloaded because the packages are on the local machine.
I believe the setup.ini is essential to the setup process, as it indicates which packages to be downloaded and installed.
The Ini file is so far only a description for file locations and paths to be set as default. It is not necessary to have the ini file if you wanna install some packages!
That´s my conclusion.
I have a lib I installed by hand (to /usr/local) on a Linux system (Eigen3, by the way). There is a FindEigen3.cmake bundled with the lib but that is not installed anywhere by default.
There is /usr/share/cmake-x.y/Modules where CMake looks for additional modules, but putting these files there doesn't seem the way to do things. Is there an equivalent place under /usr/local that is also scanned by default? Or what is the standard way of creating custom library modules?
(Although the question isn't strictly connected to programming, I think library authors may also encounter the same question from the other side: where to put these files when installing manually.)
In our project we place FIndXXX.cmake modules in folder project root dir/cmake/modules. For this to work you have to specify in project root dir/CMakeLists.txt (similiar to what DLRdave has already said):
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules)
See the comments in the CMake documentation for the "find_package" command:
http://cmake.org/cmake/help/v2.8.8/cmake.html#command:find_package
It speaks of writing a "project-config" file, and where to install it, such that find_package(Eigen3) will work without having a FindEigen3.cmake find module... It is verbose, but the information is in there.
See also user contributed wiki pages such as this one:
https://gitlab.kitware.com/cmake/community/wikis/doc/tutorials/How-to-create-a-ProjectConfig.cmake-file
You need to set the CMAKE_MODULE_PATH to include the directory that the FindEigen3.cmake file is in before calling find_package. I believe that:
set( CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} <your path> )
will do the trick, but I do not have a setup to test that available at the moment so you may have to massage that technique a bit.
I'm trying to build a Win32 DLL from an audio-DSP related Linux library (http://breakfastquay.com/rubberband/). There are makefiles and config scripts for Linux, but no help for Windows. The author provides a Win32 binary of a sample app using the library, and I see a number of "#ifdef MSVC" and "#ifdef WIN32" scattered around, so I don't think I'm starting completely from scratch but I'm stuck nevertheless.
As my programming knowledge in either platform is rather limited, I'd appreciate any help.
First of all, what is the right way to get started here? Visual Studio? Cygwin? Initially I started off creating a Win32 DLL project in Visual Studio, adding the source files, thinking about adding a .def file, etc, but at some point I felt like this was going nowhere.
As for Cygwin, this was the first time using it, and I don't even know if this is the sort of thing that Cygwin is designed for. Is it?
On Cygwin, I ran ./configure and got stuck at something like this:
"checking for SRC... configure: error: Package requirements (samplerate) were not met: No package 'samplerate' found"
After looking through the log, it appears that pkg-config is looking for samplerate.pc. How do I handle packages in Windows? libsamplerate is just an open source library, and I have source and a DLL for this. But I'm not sure how to use them to satisfy the dependency requirements for librubberband (which is what I'm trying to build)
I'm completely lost at this point and if anyone can give me a nudge in the right direction... and, is there an easier way to do this?
Many thanks in advance.
If you're still stuck on this I can throw a little light.
You may have to build everything from sources (or have the libraries installed in your environment). You're using Cygwin, I would recommend MinGW and MSYS too, but sometimes it's just not possible to use this combination to build the program or library.
So if using Cygwin, first ensure that you have a proper environment installed. This is that you have the correct development headers installed.
Then download libsndfile. Extract the sources to a directory and from the Cygwin bash shell navigate to that directory. There perform:
./configure
make
make install prefix=/cygdrive/c/cygwin
Notice that I use a prefix, that prefix should point to the directory Cygwin is installed in order to correctly install the libraries (the same happens to MinGW and MSYS, the prefix should point to the MinGW installation directory). Maybe using the usr directory in the prefix works too, I've never tried it.
Now download FFTW, as it will be needed for libsamplerate and rubberband. Same procedure as with libsndfile: extract, configure, make & make install using the prefix. Now copy the header files of FFTW (in the example they'd be in /cygdrive/c/cygwin/include) to the include directory in the usr directory (in the example /cygdrive/c/cygwin/usr/include).
Next SRC (libsamplerate), same procedure.
Then the Vamp plugin SDK. In order to compile the it you may need to edit the file src\vamp-hostsdk\PluginLoader.cpp, deleting RTLD_LOCAL from a dlopen() call (it's safe, it's already the default behaviour).
Also, you may need to install it by hand (in my experiences it didn't like the prefix). Or set the environmental variable PKG_CONFIG_PATH pointing to the paths of pkgconfig, e.g.:
set PKG_CONFIG_PATH=/cygdrive/c/cygwin/lib/pkgconfig:/usr/local/lib/pkgconfig
Now, create a file called ladspa.h in the include directory with the contents of the LADSPA header
Finally, configure and build rubberband, it should find everything it needs.
To build in MSYS using MinGW follow the same procedure, using the according prefix. Using Visual Studio is another alternative, but you may need to use some of the pre-built libraries (for example for libsndfile) as building Linux libraries natively in Windows may be complicated or even impossible (without hacking the source code) in VS.
Anyway, the autor of rubberband provides binaries; I think you should consider use them instead of going through all of this.
Linux to w32 is mostly a tricky thing.
For each of your dependencies, download the source and:
./configure
make
sudo make install
Also, I recommend you to use MinGW + msys in place of CygWin (as the latter produces executables that depend on its libraries). However in your situtation, use the VS approach -- 't will save you a lot of time.