Can RPM packages be installed into Cygwin?
Dear all, I noticed that there is a command - rpm - under Cygwin 1.7. Does that mean RPM packages can be installed into Cygwin? I tried to install ncbi-blast-2.2.26+-3.i686.rpm (see: ftp://ftp.ncbi.nlm.nih.gov/blast/executables/blast+/LATEST/ ) into Cygwin 1.7.13 with the command "install -i ncbi-blast-2.2.26+-3.i686.rpm". However, error message appeared as below. I tried to search for the missing libs using the setup.exe of Cygwin. It seems that some of them were not present, such as libc.so.6, libdl.so.2, libm.so.6, libnsl.so.1, and libz.so.1. Where can I get these libs? Thanks! $ rpm -i ncbi-blast-2.2.26+-3.i686.rpm error: Failed dependencies: /usr/bin/perl is needed by ncbi-blast-2.2.26+-3 libbz2.so.1 is needed by ncbi-blast-2.2.26+-3 libc.so.6 is needed by ncbi-blast-2.2.26+-3 libc.so.6(GLIBC_2.0) is needed by ncbi-blast-2.2.26+-3 libc.so.6(GLIBC_2.1) is needed by ncbi-blast-2.2.26+-3 libc.so.6(GLIBC_2.1.2) is needed by ncbi-blast-2.2.26+-3 libc.so.6(GLIBC_2.1.3) is needed by ncbi-blast-2.2.26+-3 libc.so.6(GLIBC_2.2) is needed by ncbi-blast-2.2.26+-3 libc.so.6(GLIBC_2.3) is needed by ncbi-blast-2.2.26+-3 libdl.so.2 is needed by ncbi-blast-2.2.26+-3 libdl.so.2(GLIBC_2.0) is needed by ncbi-blast-2.2.26+-3 libdl.so.2(GLIBC_2.1) is needed by ncbi-blast-2.2.26+-3 libgcc_s.so.1 is needed by ncbi-blast-2.2.26+-3 libgcc_s.so.1(GCC_3.0) is needed by ncbi-blast-2.2.26+-3 libgcc_s.so.1(GLIBC_2.0) is needed by ncbi-blast-2.2.26+-3 libm.so.6 is needed by ncbi-blast-2.2.26+-3 libnsl.so.1 is needed by ncbi-blast-2.2.26+-3 libpthread.so.0 is needed by ncbi-blast-2.2.26+-3 libpthread.so.0(GLIBC_2.0) is needed by ncbi-blast-2.2.26+-3 libpthread.so.0(GLIBC_2.1) is needed by ncbi-blast-2.2.26+-3 libpthread.so.0(GLIBC_2.2) is needed by ncbi-blast-2.2.26+-3 libpthread.so.0(GLIBC_2.3.2) is needed by ncbi-blast-2.2.26+-3 librt.so.1 is needed by ncbi-blast-2.2.26+-3 libstdc++.so.6 is needed by ncbi-blast-2.2.26+-3 libstdc++.so.6(CXXABI_1.3) is needed by ncbi-blast-2.2.26+-3 libstdc++.so.6(GLIBCXX_3.4) is needed by ncbi-blast-2.2.26+-3 libstdc++.so.6(GLIBCXX_3.4.5) is needed by ncbi-blast-2.2.26+-3 libz.so.1 is needed by ncbi-blast-2.2.26+-3 perl(Archive::Tar) is needed by ncbi-blast-2.2.26+-3 perl(Digest::MD5) is needed by ncbi-blast-2.2.26+-3 perl(File::Temp) is needed by ncbi-blast-2.2.26+-3 perl(File::stat) is needed by ncbi-blast-2.2.26+-3 perl(Getopt::Long) is needed by ncbi-blast-2.2.26+-3 perl(Net::FTP) is needed by ncbi-blast-2.2.26+-3 perl(Pod::Usage) is needed by ncbi-blast-2.2.26+-3 perl(constant) is needed by ncbi-blast-2.2.26+-3 perl(strict) is needed by ncbi-blast-2.2.26+-3 perl(warnings) is needed by ncbi-blast-2.2.26+-3 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can RPM packages be installed into Cygwin?
On 2012-4-7 16:12, marco atzeri wrote:
On 4/7/2012 9:40 AM, De-Jian Zhao wrote:
Dear all,
I noticed that there is a command - rpm - under Cygwin 1.7. Does that
mean RPM packages can be installed into Cygwin?
I tried to install ncbi-blast-2.2.26+-3.i686.rpm (see:
ftp://ftp.ncbi.nlm.nih.gov/blast/executables/blast+/LATEST/ ) into
Cygwin 1.7.13 with the command "install -i
ncbi-blast-2.2.26+-3.i686.rpm". However, error message appeared as
below. I tried to search for the missing libs using the setup.exe of
Cygwin. It seems that some of them were not present, such as libc.so.6,
libdl.so.2, libm.so.6, libnsl.so.1, and libz.so.1. Where can I get these
libs? Thanks!
$ rpm -i ncbi-blast-2.2.26+-3.i686.rpm
error: Failed dependencies:
/usr/bin/perl is needed by ncbi-blast-2.2.26+-3
libbz2.so.1 is needed by ncbi-blast-2.2.26+-3
libc.so.6 is needed by ncbi-blast-2.2.26+-3
{cut]
...isn't it?
from cygwin website (first page):
Cygwin is not:
-a way to run native Linux apps on Windows. You must rebuild your
application
from source if you want it to run on Windows.
-a way to magically make native Windows apps aware of UNIX®
functionality like
signals, ptys, etc. Again, you need to build your apps from
source if you want
to take advantage of Cygwin functionality.
Regards
Marco
Thanks, Marco. I was not trying to run a native linux apps, and instead
tried to rebuild the app from source. The BLAST software provides the
Build.sh and Check.sh scripts under the dirctory of
ncbi-blast-2.2.26+-src.tar\ncbi-blast-2.2.26+-src\c++\compilers\cygwin\.
So I think it is possible to run the software under cygwin. However, the
compilation stopped at "checking for python", even if python was
installed. That's to say, I installed the latest python and the
compilation could find it, but the compilation tried to search for
python2.3 and 2.4 further, and stopped when searching for 2.4.
What I am concern is that whether the i686.rpm indicates it is prepared
for cygwin. As you know, when you run "uname -smo" , you can get
something like this "CYGWIN_NT-5.1 i686 Cygwin". I think the package
ncbi-blast-2.2.26+-3.i686.rpm is for Cygwin. Is that right? Has anyone
ever succeeded in installing a RPM package into cygwin using "rpm -i *rpm"?
Regards
Dejian
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can RPM packages be installed into Cygwin?
On 2012-4-8 14:47, marco atzeri wrote: On 4/8/2012 5:10 AM, De-Jian Zhao wrote: On 2012-4-7 16:12, marco atzeri wrote: Thanks, Marco. I was not trying to run a native linux apps, and instead tried to rebuild the app from source. The BLAST software provides the Build.sh and Check.sh scripts under the dirctory of ncbi-blast-2.2.26+-src.tar\ncbi-blast-2.2.26+-src\c++\compilers\cygwin\. So I think it is possible to run the software under cygwin. However, the compilation stopped at "checking for python", even if python was installed. That's to say, I installed the latest python and the compilation could find it, but the compilation tried to search for python2.3 and 2.4 further, and stopped when searching for 2.4. What I am concern is that whether the i686.rpm indicates it is prepared for cygwin. As you know, when you run "uname -smo" , you can get something like this "CYGWIN_NT-5.1 i686 Cygwin". I think the package ncbi-blast-2.2.26+-3.i686.rpm is for Cygwin. Is that right? Has anyone ever succeeded in installing a RPM package into cygwin using "rpm -i *rpm"? Regards Dejian i686.rpm is not the source package, is the binary for linux on 686 processor. On cygwin we do not use rpm for building packages so the source rpm file will unlikely work. The source for all platforms is ftp://ftp.ncbi.nlm.nih.gov/blast/executables/blast+/LATEST/ncbi-blast-2.2.26+-src.tar.gz Regards Marco Thank you, Marco. I tried that version. Unfortunately, the compilation always stopped at "checking python" even after python was installed. It seems to me that it is a tough work to rebuild a software from the source code under Cygwin. The dependency is hard to satisfy. I am curious about the utility rpm under Cygwin environment. When running the setup.exe, I noticed that there is a rpm packge. (Search for "rpm" at the stage of "Select Packages" when running setup.exe, you can find the package under "Utils Default".) Then what is it for? Regards, Dejian -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can RPM packages be installed into Cygwin?
On 2012-4-10 8:30, Buchbinder, Barry (NIH/NIAID) [E] wrote: De-Jian Zhao sent the following at Monday, April 09, 2012 11:12 AM On 4/8/2012 5:10 AM, De-Jian Zhao wrote: On 2012-4-7 16:12, marco atzeri wrote: Thanks, Marco. I was not trying to run a native linux apps, and instead tried to rebuild the app from source. The BLAST software provides the Build.sh and Check.sh scripts under the directory of ncbi-blast-2.2.26+-src.tar\ncbi-blast-2.2.26+-src\c++\compilers\cygwin\. So I think it is possible to run the software under cygwin. However, the compilation stopped at "checking for python", even if python was installed. That's to say, I installed the latest python and the compilation could find it, but the compilation tried to search for python2.3 and 2.4 further, and stopped when searching for 2.4. What I am concern is that whether the i686.rpm indicates it is prepared for cygwin. As you know, when you run "uname -smo", you can get something like this "CYGWIN_NT-5.1 i686 Cygwin". I think the package ncbi-blast-2.2.26+-3.i686.rpm is for Cygwin. Is that right? Has anyone ever succeeded in installing a RPM package into cygwin using "rpm -i *rpm"? i686.rpm is not the source package, is the binary for linux on 686 processor. On cygwin we do not use rpm for building packages so the source rpm file will unlikely work. The source for all platforms is ftp://ftp.ncbi.nlm.nih.gov/blast/executables/blast+/LATEST/ncbi-blast-2.2.26+-src.tar.gz On 2012-4-8 14:47, marco atzeri wrote: Thank you, Marco. I tried that version. Unfortunately, the compilation always stopped at "checking python" even after python was installed. It seems to me that it is a tough work to rebuild a software from the source code under Cygwin. The dependency is hard to satisfy. I am curious about the utility rpm under Cygwin environment. When running the setup.exe, I noticed that there is a rpm package. (Search for "rpm" at the stage of "Select Packages" when running setup.exe, you can find the package under "Utils Default".) Then what is it for? Looking at the blast directory, they have a source rpm. Perhaps some source code is only available as an rpm? For what it is worth, I tried compiling and it seemed to compile OK when I used "./configure --without-boost" (recommended by make after a simple "./configure". "make check" passed two of three tests. YMMV. As I did not install any dependencies, maybe you could do better. Also, I noted that ftp://ftp.ncbi.nlm.nih.gov/blast/executables/blast+/LATEST/ contains some windows binaries. You might consider using them as native binaries usually run faster than cygwin binaries. Also, note that there is a folder ncbi-blast-2.2.26+-src/c++/compilers/cygwin. I didn't notice it until after I tried compiling. You might try to figure out whether the scripts there help you compile blast. IMPORTANT: I'm not a programmer, I don't work at NCBI, I have no experience in bioinformatics and have certainly never used BLAST. DO NOT assume that I know anything about this more than what I reported above. I was intrigued and did an experiment - that is all. Good luck. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. Disclaimer: Statements made herein are not made on behalf of NCBI. Disclaimer: Statements made herein are not made on behalf of NLM. Disclaimer: Statements made herein are not made on behalf of NIH. Disclaimer: Statements made herein are not made on behalf of PHS. Disclaimer: Statements made herein are not made on behalf of DHHS. Thank you, Barry. I tried the file c++/compilers/cygwin/build.sh but failed. I wrote to the help desk of NCBI Blast+. They have no guidelines for Cygwin users and also suggested the windows version. Actually, I am using the windows version now. The only shortcoming is that the windows binaries do not recognize the linux-like Cygwin path, so the soft links to the blast databases become invalid. I have to change to the directory of the Blast database every time I want to run blast search. Anyway, it works although a bit inconvenient. Thanks again for your help. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can RPM packages be installed into Cygwin?
It seems that the compilation under Cygwin is more complicated than expected. Thank you for your explanation, Warren. On 2012-4-10 8:49, Warren Young wrote: On 4/9/2012 9:12 AM, De-Jian Zhao wrote: the compilation always stopped at "checking python" even after python was installed. My wild guess based on no personal experience with BLAST+ is that there is some linkage error here. I'd have to try it myself (not interested) or examine the config.log file (still not interested) to figure out if this guess is correct. I'd bet there are more Cygwin-using BLAST+ users on the BLAST+ mailing list than on the Cygwin list, so you'd have a better chance of getting a solution by sending the config.log file to that list than continuing to pursue this problem here. Instead of trying to start with RPM, I'd recommend figuring out how to build BLAST+ to build from source first. You need that experience to help you build binary packages. I think you'll have an easier time learning to build a native Cygwin package than trying to get the .src.rpm file to rebuild on Cygwin: http://cygwin.com/setup.html That page gives several methods for building Cygwin packages. I'd recommend going with the Cygport option. Cygport does fewer things than RPM, so building .cygport files is easier than building RPM .spec files. (In Cygwin, much of the rest of what RPM does lives in setup.exe and cygcheck.exe.) I doubt there's enough value in the existing BLAST+ .spec file to make it an easier path for you than building a .cygport file from scratch. Then what is [the rpm package] for? It is for people who wish to build a secondary packaging system on top of Cygwin's native system. It doesn't magically port Linux RPM packages over for you. You still have to do that work yourself. And, you have to do that work without having the benefit of an ecosystem of existing RPM binary packages, upon which that BLAST+ .spec file probably depends. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can RPM packages be installed into Cygwin?
On 2012-4-17 13:58, Linda Walsh wrote: De-Jian Zhao wrote: Dear all, I noticed that there is a command - rpm - under Cygwin 1.7. Does that mean RPM packages can be installed into Cygwin? I tried to install ncbi-blast-2.2.26+-3.i686.rpm (see: ftp://ftp.ncbi.nlm.nih.gov/blast/executables/blast+/LATEST/ ) into Cygwin 1.7.13 with the command "install -i ncbi-blast-2.2.26+-3.i686.rpm". However, error message appeared as below. libc.so.6, libdl.so.2, libm.so.6, libnsl.so.1, and libz.so.1. Where can I get these libs? Thanks! $ rpm -i ncbi-blast-2.2.26+-3.i686.rpm error: Failed dependencies: /usr/bin/perl is needed by ncbi-blast-2.2.26+-3 libbz2.so.1 is needed by ncbi-blast-2.2.26+-3 libc.so.6 is needed by ncbi-blast-2.2.26+-3 libc.so.6(GLIBC_2.1.3) is needed by ncbi-blast-2.2.26+-3 libc.so.6(GLIBC_2.2) is needed by ncbi-blast-2.2.26+-3 libc.so.6(GLIBC_2.3) is needed by ncbi-blast-2.2.26+-3 . On Tue, Apr 10, 2012 at 02:03:29PM +0800, De-Jian Zhao wrote: > It seems that the compilation under Cygwin is more complicated than > expected. == This has nothing to do with cygwin. It is 'rpm' looking for installed dependencies in the rpm database. Since everything was installed with 'setup.exe' which keeps it's own 'database', rpm thinks nothing is installed. You need to make sure the versions required by the rpm are installed by setup, then you can build from a ncbi-blast-2.2.26+-3.src.rpm ^^^ The i686.rpm package is prebuilt for "some" platform (you would have to know which from the download -- i.e. one built for suse won't necessarily run on redhat, or ubuntu... or other combinations. Ones that do will be statically built and will be usable on some range of OS-versions of some particular OS. Since rpm is a linux thing, it would be built for the linux OS... so double-screw. Wrong OS, wrong executable format...etc... look for a corresponding .src. rpm, OR as someone else already suggested, look for the 'tar' that the is included in the ".src". -- in fact, if you have the .src., usually the .tar. file they build from is packed into it (then patches and OS specific stuff is applied), so you can often just take the tar from your src.rpm and move it to cygwin, and run it directly if it has a "configure" script. it might also have something like "bootstrap.sh" (or bootstrap something) that will produce a configure script -- that will usually allow you to build an executable that will work on your platform (in this case cygwin) -- but you will still have to have _needed_ dependencies installed (like development packages from cygwin for some of the above). All of those packages may not be needed -- dependencies are often based on what options you select in configure (configure --help tells you all it's options). Sometimes you don't need all the options the 'default' rpm builds with making life simpler. Compilation, period, other than on the system the package was designed for is never completely trivial, but configure makes it nearly so if it is used -- most packages these days have such a script -- rpm packages just have pre-built some pre-configured image for distribution -- may not be optimal for your needs nor is it likely to be optimized for your machine. Hope this was of some help. Good luck! Linda Thank you, Linda. When I saw the error message after installing some packages to satisfy the dependencies, I was wondering why the rpm package still complained about the already installed packages. I was not aware that cygwin and rpm were not sharing the 'database'. Thank you for making it clear to me.I will try the src.rpm when I am free. DJ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can RPM packages be installed into Cygwin?
On 2012-4-18 22:03, Christopher Faylor wrote: On Wed, Apr 18, 2012 at 09:13:20PM +0800, De-Jian Zhao wrote: On 2012-4-17 13:58, Linda Walsh wrote: [snip] Thank you, Linda. When I saw the error message after installing some packages to satisfy the dependencies, I was wondering why the rpm package still complained about the already installed packages. I was not aware that cygwin and rpm were not sharing the 'database'. Thank you for making it clear to me.I will try the src.rpm when I am free. So with all of the back and forth about this, you never realized that Cygwin's setup.exe doesn't use RPM? Wow. Wasn't the fact that there are no .rpm files in the distribution a big enough clue? cgf I never expect setup.exe will use rpm packages. There is a rpm command in Cygwin. I just thought it could be used to install a rpm package. The rpm package complained about dependencies during installation. I did think that the dependency could be solved by installing proper packages through setup.exe. But after installing some libraries through setup.exe, the rpm package still complained the same as before. It seemed that the rpm package did not see the installed libraries at all. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can RPM packages be installed into Cygwin?
On 2012-4-19 0:58, Linda Walsh wrote:
De-Jian Zhao wrote:
Thank you, Linda. When I saw the error message after installing some
packages to satisfy the dependencies, I was wondering why the rpm
package still complained about the already installed packages. I was
not aware that cygwin and rpm were not sharing the 'database'. Thank
you for making it clear to me.I will try the src.rpm when I am free.
---
Note:
The src.rpm will likely look in the rpm database for it's
pre-reqs as well.
you will need to look inside it (install the src.rpm, and look
in the /usr/src/packages/specs dir for .spec>) -- and you
will see lines like: (example from suse samba package):
BuildRequires: cups-devel e2fsprogs-devel fam-devel libacl-devel
pam-devel popt-devel python-devel readline-devel
%if 0%{?suse_version}
BuildRequires: cracklib-devel openldap2-devel
%endif
%if 0%{?suse_version} > 1030
BuildRequires: gdbm-devel pwdutils
%endif
%if 0%{?suse_version} > 930
BuildRequires: krb5-devel libiniparser-devel libnscd-devel
%endif
(there's a bunch more .. the BuildRequires lines -- will refer to
DISTRO-specific package names (if that was built for Redhat, will refer
to redhat's package names).
The "if" statements are all about configure the same "spec" file for
different
conditions... if you wanted to make things complex (I wouldn't), you
could
build all the packages it needs and put in an if statement that would
be true
for cygwin (would be alot of work!)
Or. look at the minimum set of packages you will need and make sure they
are installed from cygwin,
and comment out all those build-require lines and -- try it.. cross
fingers.
But it will then likely be built for whatever DISTRO's specific file
layout
which may not match cygwin's.
Safest -- after you install src.rpm, look in
/usr/src/packages/SOURCES/ for
.tar.[bz2,gz] -- that will be the original tar
package
-- prior to any DISTRO specific changes, that you will want.
Unpack that to a dir and hope it is setup with the configure route --
or figure
out what it needs to build (make...blah).
I have taken suse src rpms and direct ported them to cygwin -- but I had
to disable all the pre-requisite checking at build and install time,
due to
the missing rpm database -- but the program was a *simple one*, and it
worked.
So it is possible. The more complex the program, the more likely it
will
take more work to port...but sometimes you get lucky and the developer
did
a good job setting up a configure script that will work with cygwin...
It is a pain -- you will be porting the source to cygwin -- but it it
is worth it to you, you can get it done. (But you really have to want
it!) ;-)
Hi, Linda. Thank you for your detailed explanation. The "spec" file
seems different from your description. There is no explicit
BuildRequires statement. There is no explicit statement of packages
required. It is as follows:
Star ncbi-blast.spec===
Name:ncbi-blast
Version: 2.2.26+
Release: 3
Source0: %{name}-%{version}.tgz
Summary: NCBI BLAST finds regions of similarity between biological
sequences.
Exclusiveos: linux
Group: NCBI/BLAST
License: Public Domain
BuildArch: i686 x86_64
BuildRoot: /var/tmp/%{name}-buildroot
Prefix: /usr
%description
The NCBI Basic Local Alignment Search Tool (BLAST) finds regions of
local similarity between sequences. The program compares nucleotide or
protein sequences to sequence databases and calculates the statistical
significance of matches. BLAST can be used to infer functional and
evolutionary relationships between sequences as well as help identify
members of gene families.
%prep
%setup -q
%build
./configure
cd c++/*/build
%__make -f Makefile.flat
%install
%__mkdir_p $RPM_BUILD_ROOT/%_bindir
cd c++/*/bin
%__install -m755 blastp blastn blastx tblastn tblastx psiblast rpsblast
rpstblastn blast_formatter deltablast makembindex segmasker dustmasker
windowmasker makeblastdb makeprofiledb blastdbcmd blastdb_aliastool
convert2blastmask blastdbcheck legacy_blast.pl update_blastdb.pl
$RPM_BUILD_ROOT/%_bindir
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
%_bindir/*
%changelog
* Mon Jul 21 2008 Christiam Camacho
- See ChangeLog file
===End ncbi-blast.spec===
There is a file ncbi-blast-2.2.26+.tgz under the directory SOURCES.
There are two files, or build.sh and check.sh, in the directory
ncbi-blast-2.2.26+\c++\compilers\cygwin\, which is similar to the
package ncbi-blast-2.2.26+-src.tar.gz. I was stuck with "checking for
python" when compiling ncbi-blast-2.2.26+-src.tar.gz.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can RPM packages be installed into Cygwin?
On 2012-4-19 1:08, Christopher Faylor wrote: On Thu, Apr 19, 2012 at 12:05:38AM +0800, De-Jian Zhao wrote: On 2012-4-18 22:03, Christopher Faylor wrote: On Wed, Apr 18, 2012 at 09:13:20PM +0800, De-Jian Zhao wrote: On 2012-4-17 13:58, Linda Walsh wrote: [snip] Thank you, Linda. When I saw the error message after installing some packages to satisfy the dependencies, I was wondering why the rpm package still complained about the already installed packages. I was not aware that cygwin and rpm were not sharing the 'database'. Thank you for making it clear to me.I will try the src.rpm when I am free. So with all of the back and forth about this, you never realized that Cygwin's setup.exe doesn't use RPM? Wow. Wasn't the fact that there are no .rpm files in the distribution a big enough clue? I never expect setup.exe will use rpm packages. There is a rpm command in Cygwin. I just thought it could be used to install a rpm package. And, although it is a very old, basically-unmaintained package, it can be used to install rpm packages. The rpm package complained about dependencies during installation. I did think that the dependency could be solved by installing proper packages through setup.exe. But after installing some libraries through setup.exe, the rpm package still complained the same as before. It seemed that the rpm package did not see the installed libraries at all. I don't know if you are getting this or not but, yes, you can install cygwin packages which would allow you to satisfy the needs for building an rpm package. That doesn't mean that rpm would magically know about it since rpm maintains its own package database which obviously is not updated by setup.exe. So, while the programs you need to build an rpm package may be available, rpm does not know this. The fact that we use setup.exe and "cygcheck" to query our packages should be a huge clue that setup.exe does not know anything about rpm. The --nodeps option to rpm will silence the dependency warnings but it won't fix real problems if required packages are missing. rpm is basically a curiosity on Cygwin. It really isn't that useful. If you want to build Cygwin packages, you should be investigating cygport. Thank you, Christopher. Is there a way to export the package info or lib info of setup.exe to rpm? If they can share information, the problem will be easily solved. Besides, I tried --nodeps option with src.rpm. It requires root privilege (see below). However, "sudo rpm" and "su root" both failed to work. Any way to fix it? Does Cygwin has a root user? Administrator@acer /cygdrive/d/Blast/source $ rpm --nodeps --install ncbi-blast-2.2.26+-3.src.rpm warning: user coremake does not exist - using root warning: group cppcore does not exist - using root warning: user coremake does not exist - using root warning: group cppcore does not exist - using root As to cygport, it seems that a *.cygport file is required. How to get the file? $ cygport ncbi-blast-2.2.26+-3.src.rpm install *** ERROR: ncbi-blast-2.2.26+-3.src.rpm.cygport not found. Administrator@acer /cygdrive/d/Blast/source $ cygport cbi-blast-2.2.26+-src.tar.gz install *** ERROR: cbi-blast-2.2.26+-src.tar.gz.cygport not found. DJ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can RPM packages be installed into Cygwin?
On 2012-4-19 7:09, Buchbinder, Barry (NIH/NIAID) [E] wrote: De-Jian, Hello. It's me again. I suspect that just writing wrapper scripts would be faster than playing with RPMs and/or trying to compile blast yourself. As I understand it, blast programs are all command-line. I think that the easiest thing would be to just use the Windows version supplied by NCBI and write wrapper scripts that will convert cygwin's POSIX paths to Windows paths. You might have to experiment to see if you also need to convert file formats from \n to \r\n line endings. See $ man cygpath $ man dos2unix $ man unix2dos Luc Hermitte's cyg-wrapper.sh might be all you need. http://hermitte.free.fr/cygwin/#Win32 Example (using vim): http://vim.wikia.com/wiki/Running_the_win32-version_of_Vim_from_cygwin I've never used cyg-wrapper.sh, so this suggestion is "theoretical" and not based on my personal experience. Related: http://www.ncbi.nlm.nih.gov/books/NBK1762/ http://www.ncbi.nlm.nih.gov/books/NBK52637/ Good luck, - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. Disclaimer: Please see http://cygwin.com/ml/cygwin/2012-04/msg00247.html for other disclaimers and statements concerning the limited reliability of my advice on this topic. Hi,Barry. Thank you for your suggestion. Actually I am using the windows version of BLAST these days. The only inconvenience is that windows version of blast does not recognize the linux-like paths, as mentioned in my previous replies. Now, it is solved after reading your reply. I was inspired by the notion of "convert cygwin's POSIX paths to Windows paths". I tried to convert the path into windows path using "cygpath -w" and it works smoothly. An example command line is as below: blastall -p blastn -i nt.fas -d $(cygpath -w genome.db) -o test.out -m 8 I have modified the PATH variable so as to the blast programs could be automatically identified. genome.db is a soft link to the target database under the working directory. blastall can not interpret the soft link; but after translating the path using $(cygpath -w genome.db), it works perfectly. Furthermore, there is in fact no need to create the linux-style soft link. I added a variable DB to store the windows-style path of the database and this makes a more simple solution. DB="D:\Blast\blast-2.2.13\db\genome\genome.db" blastall -p blastn -i nt.fas -d $DB -o test.out -m 8 Up to now, the problem is solved. Thanks to all that participated in the discussion. I should have make it clear that I just want to use the blast program under Cygwin. The efforts were diverted into two directions. One was to compile the program from source code. Many people contributed their ideas and the discussion deepened my understanding of Cygwin. The other was to use the windows version. The problem of different styles of paths was settled today. Thanks to all for your help. Best regards, DJ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Why /usr/bin/*.dll must be executable?
Hi, When I type "cyg" and Tab, many executables starting with "cyg" are listed (Display all 262 possibilities? (y or n) y). I find that many of them are *.dll libraries under /usr/bin/. This is inconvenient to find the real executable applications (*.exe). Since *.dll files are only libraries, they are not necessary to have the attribute of "x". Thus, I run the command "chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. I closed the terminal and failed to restart Cygwin. I started my older version of Cygwin (I did not deleted it after installing a new version), and added "x" to the previous *.dll files. The dead Cygwin revived. I am confused why /usr/bin/*.dll should be executable. I thought they were only library files. When I tried to run a dll file, bash says "cannot execute binary file". Are there some hidden stories? The error messages are as follows: Administrator@acer /usr/bin $ chmod a-x *.dll Administrator@acer /usr/bin $ lh 18 [main] -bash 4512 fork: child -1 - forked process died unexpectedly, retry 0, exit code -1073741790, errno 11 -bash: fork: retry: Resource temporarily unavailable 2020930 [main] -bash 4512 fork: child -1 - forked process died unexpectedly, retry 0, exit code -1073741790, errno 11 -bash: fork: retry: Resource temporarily unavailable 4039235 [main] -bash 4512 fork: child -1 - forked process died unexpectedly, retry 0, exit code -1073741790, errno 11 -bash: fork: retry: Resource temporarily unavailable 8057832 [main] -bash 4512 fork: child -1 - forked process died unexpectedly, retry 0, exit code -1073741790, errno 11 -bash: fork: retry: Resource temporarily unavailable 16074662 [main] -bash 4512 fork: child -1 - forked process died unexpectedly, retry 0, exit code -1073741790, errno 11 -bash: fork: Resource temporarily unavailable DJ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why /usr/bin/*.dll must be executable?
On 2012-4-20 21:02, De-Jian Zhao wrote: Hi, When I type "cyg" and Tab, many executables starting with "cyg" are listed (Display all 262 possibilities? (y or n) y). I find that many of them are *.dll libraries under /usr/bin/. This is inconvenient to find the real executable applications (*.exe). Since *.dll files are only libraries, they are not necessary to have the attribute of "x". Thus, I run the command "chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. I closed the terminal and failed to restart Cygwin. I started my older version of Cygwin (I did not deleted it after installing a new version), and added "x" to the previous *.dll files. The dead Cygwin revived. I am confused why /usr/bin/*.dll should be executable. I thought they were only library files. When I tried to run a dll file, bash says "cannot execute binary file". Are there some hidden stories? The error messages are as follows: Administrator@acer /usr/bin $ chmod a-x *.dll Administrator@acer /usr/bin $ lh 18 [main] -bash 4512 fork: child -1 - forked process died unexpectedly, retry 0, exit code -1073741790, errno 11 -bash: fork: retry: Resource temporarily unavailable 2020930 [main] -bash 4512 fork: child -1 - forked process died unexpectedly, retry 0, exit code -1073741790, errno 11 -bash: fork: retry: Resource temporarily unavailable 4039235 [main] -bash 4512 fork: child -1 - forked process died unexpectedly, retry 0, exit code -1073741790, errno 11 -bash: fork: retry: Resource temporarily unavailable 8057832 [main] -bash 4512 fork: child -1 - forked process died unexpectedly, retry 0, exit code -1073741790, errno 11 -bash: fork: retry: Resource temporarily unavailable 16074662 [main] -bash 4512 fork: child -1 - forked process died unexpectedly, retry 0, exit code -1073741790, errno 11 -bash: fork: Resource temporarily unavailable DJ lh is an alias to 'ls -lh'. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why /usr/bin/*.dll must be executable?
On 2012-4-20 21:07, Václav Zeman wrote: On 20 April 2012 15:02, De-Jian Zhao wrote: Hi, When I type "cyg" and Tab, many executables starting with "cyg" are listed (Display all 262 possibilities? (y or n) y). I find that many of them are *.dll libraries under /usr/bin/. This is inconvenient to find the real executable applications (*.exe). Since *.dll files are only libraries, they are not necessary to have the attribute of "x". Thus, I run the command "chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. I closed the terminal and failed to restart Cygwin. I started my older version of Cygwin (I did not deleted it after installing a new version), and added "x" to the previous *.dll files. The dead Cygwin revived. I am confused why /usr/bin/*.dll should be executable. I thought they were only library files. When I tried to run a dll file, bash says "cannot execute binary file". Are there some hidden stories? DLLs are executables thus they need the +x bit. This is a Windows thing. If this is a windows thing, removing the x bit should not affect Cygwin. Instead, Cygwin is corrupted after removing the x bit. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why /usr/bin/*.dll must be executable?
On 2012-4-21 0:27, Corinna Vinschen wrote: On Apr 21 00:17, De-Jian Zhao wrote: On 2012-4-20 21:07, Václav Zeman wrote: On 20 April 2012 15:02, De-Jian Zhao wrote: Hi, When I type "cyg" and Tab, many executables starting with "cyg" are listed (Display all 262 possibilities? (y or n) y). I find that many of them are *.dll libraries under /usr/bin/. This is inconvenient to find the real executable applications (*.exe). Since *.dll files are only libraries, they are not necessary to have the attribute of "x". Thus, I run the command "chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. I closed the terminal and failed to restart Cygwin. I started my older version of Cygwin (I did not deleted it after installing a new version), and added "x" to the previous *.dll files. The dead Cygwin revived. I am confused why /usr/bin/*.dll should be executable. I thought they were only library files. When I tried to run a dll file, bash says "cannot execute binary file". Are there some hidden stories? DLLs are executables thus they need the +x bit. This is a Windows thing. If this is a windows thing, removing the x bit should not affect Cygwin. Instead, Cygwin is corrupted after removing the x bit. Windows requires the x bit for DLLs to be loadable as executable code into the address space of a process. As Václav wrote, it's a Windows thing. Can Windows see the rwx bits assigned by Cygwin to the files? I tried removing the x bit of an executable file blastall.exe (chmod a-x blastall.exe); the file can not be executed under Cygwin, but still can be executed under cmd console of Windows. It seems that Windows does not honor the rwx bits assigned by Cygwin. Is there a detailed description of the starting process of Cygwin system? Or, how does Cygwin interact with *.dll files? After starting Cygwin, I ran "chmod a-x /usr/bin/cygperl5_10.dll" and perl could not be started any more. This could be cured by ran "chmod a+x /usr/bin/cygperl5_10.dll". It seems to me that the Cygwin binary executables will communicate with their corresponding *.dll files when executed. The *.dll provide the required functions and subroutines and that's enough. There is no need to mark *.dll with an x bit. I have no strong background of computer science. Maybe there is some basic knowledge beyond my imagination. Hope you can help disclose it to me. Thanks. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why /usr/bin/*.dll must be executable?
On 2012-4-21 1:29, Larry Hall (Cygwin) wrote: On 4/20/2012 1:25 PM, Nellis, Kenneth wrote: From: Corinna Vinschen Windows requires the x bit for DLLs to be loadable as executable code into the address space of a process. As Václav wrote, it's a Windows thing. So, I had to play with "chmod -x cyg*.dll" and, of course, it totally hosed Cygwin. I recovered by reinstalling from scratch only after realizing that ATTRIB did not have an option to re- establish X--we're talking XP here. So, as this is a Windows thing, wondering how, through Windows, I could restore execute access to the DLLs. What's wrong with "chmod +x cyg*.dll"? It doesn't work any more. You cannot restart a new terminal, either. You will be trapped here. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why /usr/bin/*.dll must be executable?
On 2012-4-21 1:40, Larry Hall (Cygwin) wrote: On 4/20/2012 1:32 PM, De-Jian Zhao wrote: On 2012-4-21 0:27, Corinna Vinschen wrote: On Apr 21 00:17, De-Jian Zhao wrote: On 2012-4-20 21:07, Václav Zeman wrote: On 20 April 2012 15:02, De-Jian Zhao wrote: Hi, When I type "cyg" and Tab, many executables starting with "cyg" are listed (Display all 262 possibilities? (y or n) y). I find that many of them are *.dll libraries under /usr/bin/. This is inconvenient to find the real executable applications (*.exe). Since *.dll files are only libraries, they are not necessary to have the attribute of "x". Thus, I run the command "chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. I closed the terminal and failed to restart Cygwin. I started my older version of Cygwin (I did not deleted it after installing a new version), and added "x" to the previous *.dll files. The dead Cygwin revived. I am confused why /usr/bin/*.dll should be executable. I thought they were only library files. When I tried to run a dll file, bash says "cannot execute binary file". Are there some hidden stories? DLLs are executables thus they need the +x bit. This is a Windows thing. If this is a windows thing, removing the x bit should not affect Cygwin. Instead, Cygwin is corrupted after removing the x bit. Windows requires the x bit for DLLs to be loadable as executable code into the address space of a process. As Václav wrote, it's a Windows thing. Can Windows see the rwx bits assigned by Cygwin to the files? I tried removing the x bit of an executable file blastall.exe (chmod a-x blastall.exe); the file can not be executed under Cygwin, but still can be executed under cmd console of Windows. It seems that Windows does not honor the rwx bits assigned by Cygwin. Is there a detailed description of the starting process of Cygwin system? Or, how does Cygwin interact with *.dll files? After starting Cygwin, I ran "chmod a-x /usr/bin/cygperl5_10.dll" and perl could not be started any more. This could be cured by ran "chmod a+x /usr/bin/cygperl5_10.dll". It seems to me that the Cygwin binary executables will communicate with their corresponding *.dll files when executed. The *.dll provide the required functions and subroutines and that's enough. There is no need to mark *.dll with an x bit. I have no strong background of computer science. Maybe there is some basic knowledge beyond my imagination. Hope you can help disclose it to me. Thanks. Cygwin DLLs are no different than native Windows DLLs when it comes to loading them. The Windows loader is responsible for loading them. So we're stuck with whatever restrictions the Windows loader imposes on Windows apps. Yes. But does Windows loader can see the x bit assigned by Cygwin, a quite different OS? At least, *.exe does not respect or even is blind to the -x operation of Cygwin, as abovementioned. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why /usr/bin/*.dll must be executable?
On 2012-4-21 1:57, Larry Hall (Cygwin) wrote: On 4/20/2012 1:47 PM, De-Jian Zhao wrote: On 2012-4-21 1:40, Larry Hall (Cygwin) wrote: On 4/20/2012 1:32 PM, De-Jian Zhao wrote: On 2012-4-21 0:27, Corinna Vinschen wrote: On Apr 21 00:17, De-Jian Zhao wrote: On 2012-4-20 21:07, Václav Zeman wrote: On 20 April 2012 15:02, De-Jian Zhao wrote: Hi, When I type "cyg" and Tab, many executables starting with "cyg" are listed (Display all 262 possibilities? (y or n) y). I find that many of them are *.dll libraries under /usr/bin/. This is inconvenient to find the real executable applications (*.exe). Since *.dll files are only libraries, they are not necessary to have the attribute of "x". Thus, I run the command "chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. I closed the terminal and failed to restart Cygwin. I started my older version of Cygwin (I did not deleted it after installing a new version), and added "x" to the previous *.dll files. The dead Cygwin revived. I am confused why /usr/bin/*.dll should be executable. I thought they were only library files. When I tried to run a dll file, bash says "cannot execute binary file". Are there some hidden stories? DLLs are executables thus they need the +x bit. This is a Windows thing. If this is a windows thing, removing the x bit should not affect Cygwin. Instead, Cygwin is corrupted after removing the x bit. Windows requires the x bit for DLLs to be loadable as executable code into the address space of a process. As Václav wrote, it's a Windows thing. Can Windows see the rwx bits assigned by Cygwin to the files? I tried removing the x bit of an executable file blastall.exe (chmod a-x blastall.exe); the file can not be executed under Cygwin, but still can be executed under cmd console of Windows. It seems that Windows does not honor the rwx bits assigned by Cygwin. Is there a detailed description of the starting process of Cygwin system? Or, how does Cygwin interact with *.dll files? After starting Cygwin, I ran "chmod a-x /usr/bin/cygperl5_10.dll" and perl could not be started any more. This could be cured by ran "chmod a+x /usr/bin/cygperl5_10.dll". It seems to me that the Cygwin binary executables will communicate with their corresponding *.dll files when executed. The *.dll provide the required functions and subroutines and that's enough. There is no need to mark *.dll with an x bit. I have no strong background of computer science. Maybe there is some basic knowledge beyond my imagination. Hope you can help disclose it to me. Thanks. Cygwin DLLs are no different than native Windows DLLs when it comes to loading them. The Windows loader is responsible for loading them. So we're stuck with whatever restrictions the Windows loader imposes on Windows apps. Yes. But does Windows loader can see the x bit assigned by Cygwin, a quite different OS? Cygwin is not an O/S. The basis for Cygwin is the emulation _DLL_, cygwin1.dll. Cygwin executables and DLLs are Windows binaries, subject to whatever limitations the Windows loader has. That's it. If you're not happy about that, you should complain to MS about it. Then, what limitations does the Windows loader have? As far as I know, there is no x bits for windows, right? How does the "chmod a-x" affect the file behavior under Windows if this is a Windows thing? I am completely confused. When I ran "chmod a-x *.dll", I assumed that these dll files were not executed directly under Cygwin or Windows; they were just some files storing the required functions or something; removing the x bits should not affect the behavior of Cygwin and Windows. If have run "chmod a-x" on the Windows system dll files, that will lead to the corruption of Windows, right? Thank God. I didn't do that. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why /usr/bin/*.dll must be executable?
On 2012-4-21 3:06, Jon TURNEY wrote: On 20/04/2012 14:02, De-Jian Zhao wrote: When I type "cyg" and Tab, many executables starting with "cyg" are listed (Display all 262 possibilities? (y or n) y). I find that many of them are *.dll libraries under /usr/bin/. This is inconvenient to find the real executable applications (*.exe). 'export EXECIGNORE=*.dll' is a cygwin extension to bash to tell it you don't want to see those pesky dlls. See /usr/share/doc/Cygwin/bash.README Cool! That's just what I need! Thanks, Jon. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
