Problem: I'm writing some code that is portable to Linux and Cygwin (compiled on msys), and the handling of symlinks is different. On Cygwin, if I create a symlink in the normal way, with a default Cygwin shell (ie. the CYGWIN envvar not set):
$ ln -s foo bar
then fopen(bar) doesn't follow the symlink. The first line of text appears to be !<symlink>. and my code reports that the opened file isn't UTF-8.
I can fix this by running Cygwin as admin, setting CYGWIN to winsymlinks:nativestrict, deleting the symlink, and re-creating it. However, this isn't ideal: in my case, the symlinks are created by Subversion from the Linux codebase, so I now need to script the link delete and remake after every update.
Is there a better way to do this, or do I have to ask Cygwin users
to run as admin, and set CYGWIN?
How do I write code to follow a native Cygwin symlink?
How do I write code to find out what type of symlink I'm dealing
with? This is also asked here, but the answer there is scripted
Thanks.
Edit
Ok, I think the answer is basically here, on the MinGW mailing list, from 2007. If you compile with MinGW you can't use Cygwin native symlinks. Maybe the situation has changed since 2007?
Related
Once a program is installed in Linux, sometimes I find out that it is easier to put in a different location. In general, what is the significance of the location of the files of an installed program on Linux?
Often the advice on the internet is to add the (wrong or inconvenient) paths to environment variables. I'd much rather move the files to locations where they are automatically found by commands and programs.
One recent example is site-packages of Python. My Python did not appear to check the PYTHONPATH variable, moving the libraries there to the Python2.7/ directory worked well.
Now Ia m facing the same issue with OpenCV.
I also wonder why Linux installation does not prompt (like Windows) for the desired installation directory and why, so often, things wind up in places where they don't work?
In general, programs are installed in /usr/bin (for binaries) and /usr/lib, or a specific path to that specific linux distro, so that any program that you install that uses a specific library/program will search in that path for it. If you install a program in a different path, let's say /home/user/program, it will be installed locally and other programs won't be able by default to access it.
You can install any program wherever you want. However, it is good use to use the repo and install them in the general path.
I don't know how you install programs, but I use apt-get and dpkg on Ubuntu. You can also install some python modules this way.
Generally you are supposed to use the package system provided by your distro (IMHO).
If you do not use packages then you are on your own.
About PYTHONPATH. Did you add it to your .bashrc and made sure that it was set in the terminal you are using?
Also please see:
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
The current directory on cygwin is home/myuser. I navigated to cygwin and found it has a directory called home/myuser and could not figure out how I would navigate to the desktop. I did not want to add a desktop directory there and I could not navigate above the root folder (cygwin). Any idea on how I could do this?
This is essentially covered in the Cygwin FAQ under "How can I access other drives?". No, you're not trying to access another drive, but you are trying to access a folder outside of the Cygwin tree. As the FAQ item says, Cygwin maps your Windows drives as /cygdrive/<drive-letter>, so your desktop is likely something like /cygdrive/c/Users/<username>/Desktop. Note that the path has changed over the years with various versions of Windows and you didn't specify what version you're running, so it may not be exactly that.
Anyway, what I would do, would be to create a symbolic link to that from my Cygwin home folder. Something like this:
ln -s "/cygdrive/c/Users/<username>/Desktop" Desktop
I put the quotes in because depending on what version of windows you have, this path may include spaces.
You'll probably notice from the FAQ that the Cygwin version of bash accepts DOS-style pathnames, so you can actually do the following:
cd "C:/Users/<username>/Desktop"
But I recommend avoiding such syntax. Not all Cygwin apps understand DOS-style paths, and you'll only end up confusing yourself if you have to try to figure out whether what you're doing will work with a DOS-style path or not. It's best to just use the Unix-style paths for everything when in the Cygwin environment, unless you have a very good reason not to.
Add
cd "/cygdrive/c/Users/<username>/Desktop"
to .bashrc file located in <cygwin install directory>/home/<username>. This will change working directory to desktop every time you open Cygwin terminal.
I'm getting "skipping XXX: it is not a regular file" every time I run ctags -R XXX. For one reason or another, ctags on Cygwin isn't recursing directories. Surely, I must be doing something stupid.
Whenever I try the de-facto standard ctags -R in my project root, it complains that I didn't specify any input files. When I specify a directory, it seems to think its a file.
I'm a tad stumped. I installed a fresh Cygwin build last week from scratch. I installed everything. I rarely use Cygwin. ctags works perfectly on all my BSD, Linux, Mac and Solaris boxes.
I thought Perforce's read-only permissions might have been the culprit, but chmod 777 changes nothing.
Any ideas? Should I recompile from source?
As is currently being discussed on the Cygwin mailing list, the xemacs-tags and ctags packages both install /bin/ctags. The behaviour you're seeing is from the xemacs version.
The developers will sort it out, although that may take a little while. In the meantime, do the following to get Exuberant Ctags (with its working -R option) installed:
Run the Cygwin installer again (download setup.exe again if you need to).
At the package list, search for "tags" and click the "New" column for both "ctags" and "xemacs-tags" until they say either "Skip" or "Uninstall" (one's under "Devel", the other under "Editors".
Hit "Next".
Once the install has completed, click "Back" instead of "Finish" (if you do this wrong, just restart the installer).
At the package list, select to install "ctags" only. As of today (12 December 2012), that'll specify version 5.8-1.
Click Next and let the install finish.
That'll give you the "ctags" package without the "xemacs-tags" package, and you should be good to go.
I'm getting the same problem, just installed full Cygwin Oct 2012. Downloaded Exuberant Ctags source, compiled, and no more problem.
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.
I've written a C++ program (command line, portable code) and I'm trying to release a Linux version at the same time as the Windows version. I've written a makefile as follows:
ayane: *.cpp *.h
g++ -Wno-write-strings -oayane *.cpp
Straightforward enough so far; but I'm given to understand it's customary to have a second step, make install. So when I put the install: target in the makefile... what command should be associated with it? (If possible I'd prefer it to work on all Unix systems as well as Linux.)
Installation
A less trivial installer will copy several things into place, first insuring that the appropriate paths exists (using mkdir -p or similar). Typically something like this:
the executable goes in $INSTALL_PATH/bin
any libraries built for external consumption go in $INSTALL_PATH/lib or $INSTALL_PATH/lib/yourappname
man pages go in $INSTALL_PATH/share/man/man1 and possibly other sections if appropriate
other docs go in $INSTALL_PATH/share/yourappname
default configuration files go in $INSTALL_PATH/etc/yourappname
headers for other to link against go in $INSTALL_PATH/include/yourappname
Installation path
The INSTALL_PATH is an input to the build system, and usually defaults to /usr/local. This gives your user the flexibility to install under their $HOME without needing elevated permission.
In the simplest case just use
INSTALL_PATH?=/usr/local
at the top of the makefile. Then the user can override it by setting an environment variable in their shell.
Deinstallation
You also occasionally see make installs that build a manifest to help with de-installation. The manifest can even be written as a script to do the work.
Another approach is just to have a make uninstall that looks for the things make install places, and removes them if they exist.
In the simplest case you just copy the newly created executable into the /usr/local/bin path. Of course, it's usually more complicated than that.
Notice that most of these operations require special rights, which is why make install is usually invoked using sudo.
make install is usually the step that "installs" the binary into the correct place.
For example, when compiling Vim, make install may place it in /usr/local/bin
Not all Makefiles have a make install