Building astrometry.net on RHEL 7

[Elisabeth Atems]

Hello, I'm new to this group. Apologies if this has been answered before, but I tried searching on RHEL and found only one post from two years ago, that did not address my question.

I am running Scientific Linux 7.9, which derives from RHEL 7. I have tried building astrometry.net from source following these instructions for CentOS 7.8 linked to from the astrometry.net web page. As I understand it, CentOS 7 is another offshoot of RHEL 7 so this could be expected to work... but it does not. "Out of the box", with only the mods mentioned at the above link, it bombs when compiling catalogs/ucac5tofits.c with a dialect error complaining about "for loop initial declarations".

That problem was easily circumvented by adding -std=c99 to CFLAGS. But then the build failed again when linking build-hd-tree, with a slew of errors about multiply defined functions in catalogs/tycho2-fits.o and util/bl.o. That's much more serious and I have no idea of the cause, or how to fix it.

Has anyone else encountered this, and most importantly, does anyone know how to fix it?

Thanks in advance.

-Liz

[Dustin Lang]

Hi,

I'm not sure if this will be helpful at all, but here are CentOS 8 instructions

https://github.com/dstndstn/astrometry.net/blob/main/.circleci/config.yml#L202

or CentOS 7

https://github.com/dstndstn/astrometry.net/blob/main/.circleci/config.yml#L258

or a more recent Rocky Linux

https://github.com/dstndstn/astrometry.net/blob/main/.circleci/config.yml#L314

I don't use RedHat derivatives so I don't really know anything about how the various branches' versions compare with each other.

If you want to send full build logs (eg with "make > log 2>&1"), we may have things to suggest.  The errors you're describing don't sound familiar to me.

It would also be useful to report which version of gcc you're using.  (gcc --version)

cheers,

dustin

--
You received this message because you are subscribed to the Google Groups "astrometry" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astrometry+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/astrometry/3d205971-fd96-4c7f-8e49-214d4ecb251an%40googlegroups.com.

[Elisabeth Atems]

Hi Dustin,

Thanks, in fact the CentOS 7 instructions in your links are pretty much the same as the ones that I followed, at least through the make and make install steps. No joy, unfortunately. :(

%gcc --version

gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)

I'm attaching the log file - it's not a log of the full compilation as everything up to the attempt to link build-hd-tree succeeded previously, and I didn't do a make clean.

Liz

[Elisabeth Atems]

FWIW, here's a full log of the build attempt, after 'make clean'. Maybe it will be more helpful.

Thanks,

Liz

[Dustin Lang]

Hi Liz,

Thanks for sending that.  It looks like some issue with the way your version of gcc handles inlining.

Based on your previous messages I'm assuming this is the log file you get when you've set CPPFLAGS="-std=c99".  Can you try:

- unset CPPFLAGS or any other environment variables like that

- export NETPBM_INC="-I/usr/include/netpbm"

- grab a newer astrometry.net: eg   git clone https://github.com/dstndstn/astrometry.net.git

 (that warning in ucac5tofits.c was fixed since version 0.89)

- try to make again

cheers,

dustin

To view this discussion on the web visit https://groups.google.com/d/msgid/astrometry/d97cd355-a291-41b8-8ad2-17c26655a979n%40googlegroups.com.

[Elisabeth Atems]

My bad for not keeping the exchange with Dustin on the group... forgot to do a cc.

Anyway, the main problem is solved, with Dustin's help! Redux:  astrometry.net-0.89 does NOT build on RHEL 7, or at least not on SL 7.9. I needed to clone the source code tree from github, and really nothing else other than maybe making sure /usr/include/netpbm was in the includes search path.

There is still one outstanding problem, namely that cairoutils.c and plotquad.c don't compile due to the compiler not being able to find cairo.h. This was NOT fixed by putting /usr/include/cairo in the includes search path, i.e.

%setenv CAIRO_INC "-I/usr/include/cairo"

from the C-shell prior to make.

I realise these utilities are "eye-candy", but I'd still like to have them. Any ideas? (The output of `make install` is attached.)

Thanks,

Liz

[Dustin Lang]

Hmm, those built for me -- do you have the cairo-devel package installed?

To view this discussion on the web visit https://groups.google.com/d/msgid/astrometry/c6fb0c2d-d563-4f74-a936-aa977ff72fb7n%40googlegroups.com.

[Elisabeth Atems]

Yes.

Liz

[Elisabeth Atems]

It appears that -I/usr/include/cairo isn't on the gcc command line for at least cairoutils.c. Maybe CAIRO_INC doesn't do what I thought? Any other way to force it onto the command line?

Liz

[Dustin Lang]

We use "pkg-config --cflags cairo" to get the flags.

I spun up a SL7 docker container and I have:

# yum list cairo-devel
Loaded plugins: ovl
Installed Packages
cairo-devel.x86_64                                                                                     1.15.12-4.el7                                                                                     @sl
Available Packages
cairo-devel.i686                                                                                       1.15.12-4.el7

and I get:

# pkg-config --cflags cairo
-I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/uuid -I/usr/include/libdrm

To view this discussion on the web visit https://groups.google.com/d/msgid/astrometry/a9139f9f-d5ef-4339-b145-e0f3d8cbd1c5n%40googlegroups.com.

[Elisabeth Atems]

Yup, that's what I found by perusing the makefiles. Despite your use of "?=" in the makefiles which should have set CAIRO_INC, this didn't work. I had to manually run pkg-config --cflags and --libs and copy and paste the output into util/makefile.cairo. Then I found that the compiler found cairo.h but failed on ppm.h, part of netpbm-devel, so I did the same thing for util/makefile.netpbm, and it seems to have worked. I'm attaching the make install output for completeness, but I don't see any problems myself.

The big mystery for me is why setting environment variables worked for 'make' but not 'make install'. To be exact, I did 'sudo make install', first verifying that sudo passes the environment on to the child shell. Is it possible that the *shell* fails to pass the environment on to make when invoked via sudo?

Thanks again for your help,

Liz

[Elisabeth Atems]

> Is it possible that the *shell* fails to pass the environment on to make when invoked via sudo?

Actually, "sudo ps" shows only ps and sudo running, so it appears that sudo doesn't fork a new shell after all, but just runs the command directly. Which makes it even stranger (to me) that make doesn't inherit the environment from the shell that invokes sudo.

Weird...

Liz