astrometry.net-0.43 and cygwin

254 views
Skip to first unread message

Andy Galasso

unread,
Apr 24, 2013, 9:48:50 AM4/24/13
to astro...@googlegroups.com
Hi Dustin,

I just went through the exercise of getting 0.43 to build and run on cygwin. In doing so, I came across 3 problems:

a) various Makefile rules refer to "file.so", but the tools under cygwin sometimes create them as "file.dll"

b) The -fPIC option in util/makefile.common causes a warning that gets treated as an error (-Werror) when generating os-features-config.h, leading to an incorrect value of NEED_SWAP_QSORT_R and a runtime crash.

c) in run_command_get_outputs() in util/ioutils.c, for some reason, select() under cygwin is returning ready bits in errset. Although this seems like a possible cygwin bug to me, I think it is safe to ignore errset in general. Error conditions like EOF are reported on readfds or writefds. errset is really only required to test for "exceptional" conditions like MSG_OOB data on a tcp socket, and should be irrelevant for the stdout/stderr pipes.

Attached is a very hacky patch which crudely fixes those issues. I wanted to run things by you before proceeding further, to see if you are interested incorporating support for cygwin. If you like, I can work on a more portable patch. Or else, if you prefer, you could take it from here.

Thanks,
Andy Galasso
astrometry.net-0.43-cygwin.patch

Dustin Lang

unread,
Apr 24, 2013, 10:05:48 AM4/24/13
to astro...@googlegroups.com
Thanks for this, Andy!

Could you please tell me what this does on your cygwin box?

```
python -c "import sysconfig; print sysconfig.get_config_var('SO')"
```

On my Mac OSX it says ".so", so if that does the right thing on yours too then we can replace the hard-coded ".dll" string in your diff.

By the way, you say the cygwin tools "sometimes" create .dll files -- that "sometimes" makes me a bit nervous!  Could you explain?  If, instead of creating .dll files, we were explicit in setting the output filename to ".so", do things work or break?

Your comments on ignoring select()'s errset sound reasonable, since here we're just connecting to a subprocess's std streams

thanks,
dustin

Andy Galasso

unread,
Apr 24, 2013, 10:34:49 AM4/24/13
to astro...@googlegroups.com
On Wednesday, April 24, 2013 10:05:48 AM UTC-4, Dustin Lang wrote:

Could you please tell me what this does on your cygwin box?
 
cygwin$ python -c "import sysconfig; print sysconfig.get_config_var('SO')"
.dll 
 
On my Mac OSX it says ".so", so if that does the right thing on yours too then we can replace the hard-coded ".dll" string in your diff.

Great, sounds like a good solution!
 
By the way, you say the cygwin tools "sometimes" create .dll files -- that "sometimes" makes me a bit nervous!  Could you explain?  If, instead of creating .dll files, we were explicit in setting the output filename to ".so", do things work or break?

AFAICT, .dll files were produced by tools like swig, but .so files were produced by the gcc link commands in the makefiles. So if we fix the makefiles to use the platform-specific filename extension, we should be all set.
 
Your comments on ignoring select()'s errset sound reasonable, since here we're just connecting to a subprocess's std streams
 
Great, thanks!

Andy

Maik Riechert

unread,
Dec 17, 2013, 2:41:43 PM12/17/13
to astro...@googlegroups.com
Hi,

I'd like to revive this thread as I'm having the same problem with the .so/.dll ending. make and make extra work, and make install fails with the first Python extension. Python builds _cutils.dll which is what it later expects and which is exactly what 'python -c "import sysconfig; print sysconfig.get_config_var('SO')"' returns as suffix. So for the python extensions, the Makefiles could be improved by determining the suffix with the above one-liner as already suggested. By the way, libastrometry.so doesn't get a .dll ending, it's just the python extensions as far as I see. Should I go through it on 0.46 and supply a patch?

Cheers
Maik

Dustin Lang

unread,
Dec 17, 2013, 3:29:28 PM12/17/13
to astro...@googlegroups.com
I'd be happy to get a patch for this!

Maik Riechert

unread,
Dec 18, 2013, 3:59:27 PM12/18/13
to Dustin Lang, astro...@googlegroups.com
Attached are the patches for each file I changed. It actually works! In
detail:

I introduced a PYTHON_SO_EXT variable in makefile.common which I use in
the other Makefiles and which contains ".so" or ".dll", respectively.

Also, the warnings caused by -fPIC and which cause the SWAP_QSORT_R test
to fail (mentioned in the first post) can be prevented by using -fpic
instead. I got this from the 5th comment of
http://stackoverflow.com/q/16708148/60982 It's in the patch for
makefile.common.

Regarding the ignoring of select()'s errset, I had to do that as well
and just copied the change from the original patch. But this should be
completely removed, I mean the lines which handle errset.

With these patches I could get it compiled in cygwin by doing the
following beforehand:

1. chmod +x \etc\profile.d\lapack0.sh
I don't know why +x is not set, but this prevents numpy from working.
The cygwin console has to be restarted after this. It includes lapack in
the PATH.

2. cfitsio as usual, for me:
export CFITS_INC="-I/cygdrive/c/dev/_sources/cfitsio/include"
export CFITS_LIB="-L/cygdrive/c/dev/_sources/cfitsio/lib -lcfitsio"

3. netpbm can be installed through cygwin and then needs:
export NETPBM_INC="-I/usr/include/netpbm"
export NETPBM_LIB="-L/lib -lnetpbm"

After 'make install' the python files in the folder
/usr/local/astrometry/lib/python/astrometry/util/
all had 000 rights which then lead to runtime failures. So I adapted the
rights with:
chmod 644 /usr/local/astrometry/lib/python/astrometry/util/*
chmod +x /usr/local/astrometry/lib/python/astrometry/util/*

And finally, it worked.

Cheers
Maik
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "astrometry" group.
> Visit this group at http://groups.google.com/group/astrometry.

blind.patch
common.patch
ioutils.patch
libkd.patch
sdss.patch
util.patch

Karsten Schindler

unread,
Feb 26, 2014, 8:46:00 PM2/26/14
to astro...@googlegroups.com, Dustin Lang, neothe...@googlemail.com
Does anybody know if there is any chance that an updated version will become available in the cygwin repository soon? Would be of great help - current version is 0.38-2.

Thanks,
Karsten

Dustin Lang

unread,
Feb 27, 2014, 9:42:06 AM2/27/14
to astro...@googlegroups.com, Dustin Lang, neothe...@googlemail.com

Hi,

Has there even been a package contributed to the cygwin repository?  (ie, that can be set up via setup.exe)?  I never have done that.  To my knowledge, people have only installed it manually from source.

cheers,
--dustin

Andrew Hood

unread,
Feb 27, 2014, 5:43:08 PM2/27/14
to astro...@googlegroups.com
Dustin, there is/was one but not in the usual cygwin repositories. The URL starts http://astrotortilla.comsix.fi and has version 0.38
Andrew
--
You received this message because you are subscribed to the Google Groups "astrometry" group.

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4335 / Virus Database: 3705/7128 - Release Date: 02/26/14



-- 
There's no point in being grown up if you can't be childish sometimes.
-- Dr. Who
Reply all
Reply to author
Forward
0 new messages