Building astrometry.net on RHEL 7

24 views
Skip to first unread message

Elisabeth Atems

unread,
Jul 5, 2022, 8:27:34 PMJul 5
to astrometry
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

unread,
Jul 5, 2022, 9:06:30 PMJul 5
to Elisabeth Atems, astrometry
Hi,

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

or CentOS 7

or a more recent Rocky Linux

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

unread,
Jul 5, 2022, 10:36:09 PMJul 5
to Dustin Lang, astrometry
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
make.log

Elisabeth Atems

unread,
Jul 5, 2022, 11:32:28 PMJul 5
to astrometry
FWIW, here's a full log of the build attempt, after 'make clean'. Maybe it will be more helpful.

Thanks,
Liz
make.log

Dustin Lang

unread,
Jul 6, 2022, 8:52:47 AMJul 6
to Elisabeth Atems, astrometry
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"
 (that warning in ucac5tofits.c was fixed since version 0.89)
- try to make again

cheers,
dustin

Elisabeth Atems

unread,
Jul 6, 2022, 12:03:00 PMJul 6
to astrometry
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
install2.log

Dustin Lang

unread,
Jul 6, 2022, 12:11:26 PMJul 6
to Elisabeth Atems, astrometry
Hmm, those built for me -- do you have the cairo-devel package installed?


Elisabeth Atems

unread,
Jul 6, 2022, 12:12:17 PMJul 6
to Dustin Lang, astrometry
Yes.

Liz

Elisabeth Atems

unread,
Jul 6, 2022, 12:18:23 PMJul 6
to astrometry
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

unread,
Jul 6, 2022, 12:48:13 PMJul 6
to Elisabeth Atems, astrometry
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





Elisabeth Atems

unread,
Jul 6, 2022, 12:58:32 PMJul 6
to Dustin Lang, astrometry
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
install5.log

Elisabeth Atems

unread,
Jul 6, 2022, 1:13:01 PMJul 6
to astrometry
> 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
Reply all
Reply to author
Forward
0 new messages