bugGNU Astronomy Utilities - Bugs: bug #48076, GSL linking problem in Ubuntu


You are not allowed to post comments on this tracker with your current authentication level.

bug #48076: GSL linking problem in Ubuntu

Submitter:  Mohammad Akhlaghi <makhlaghi>
Submitted:  Wed 01 Jun 2016 12:58:28 PM UTC
Category:  Installation Severity:  4 - Important
Item Group:  Crash Status:  Fixed
Privacy:  Public Assigned to:  makhlaghi
Open/Closed:  Closed

Jump to the original submission

Thu 02 Jun 2016 07:51:35 AM UTC, comment #9: 

I can reproduce the reported bug on "gnuastro_v0.1" tag with

./configure LDFLAGS="-Wl,--as-needed"

and can confirm that it's fixed now in HEAD.  So, I don't need to get an Ubuntu box for confirmation.

Ok, I'm fine with waiting a short period in order to see whether other bug reports will come, but after that period I suggest to roll a new version in any case.

Mosè Giordano <giordano>
Group Member
Thu 02 Jun 2016 07:37:47 AM UTC, comment #8: 

You are right, on the main webpage I added a line (which starts with "Bug fixed" in bold) immediately under the first download link. I also uploaded an alpha-release (gnuastro-alpha-latest.tar.gz) on alpha.gnu.org and put a link to it there. So hopefully if someone comes to the top page, they will be guided to the proper tarball to download. I also put a comment on that reddit page.

Lets wait a little more longer (maybe a week or two) to see if any other major/minor issues come up, then we will make the 0.2 release. Do you think this sound reasonable, or should we make it the next day or two ;-)?

Mohammad Akhlaghi <makhlaghi>
Group administrator
Thu 02 Jun 2016 07:27:40 AM UTC, comment #7: 

I'll be able to get an Ubuntu box next week, for the time being I can only confirm that I can build the project on Debian.  Anyway, I see that the effect of your latest commit is to move the linking libraries after the object, in the Makefiles, as it should be, so I expect that it'll work on Ubuntu as well.

Since this is a serious FTBFS (Fails To Build From Source) bug for some systems (including a very common one), I suggest a quick new release after we make sure it really works on Ubuntu.

Mosè Giordano <giordano>
Group Member
Thu 02 Jun 2016 06:37:52 AM UTC, comment #6: 

Sorry, I forgot to actually mark the bug as closed and fixed!

Mohammad Akhlaghi <makhlaghi>
Group administrator
Thu 02 Jun 2016 06:19:21 AM UTC, comment #5: 

The implementation is complete and I was able to successfully build Gnuastro on Ubuntu 14.04. The fix is pushed to master and I am marking the bug as fixed. But I would be greatful if you could still try it out for a double check.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Thu 02 Jun 2016 03:19:30 AM UTC, comment #4: 

I believe I have found the solution and I am busy implementing it now, I will just outline it here:

The root of the problem was actually in the Autoconf functions that check for libraries, until now we were using AC_CHECK_LIB and I had the ACTION_IF_FOUND was set to define an unused "absolutejunk" variable. When ACTION_IF_FOUND is defined in AC_CHECK_LIB, it will not append the library to the LIBS variable which will be used by Automake.

As I had described in the comments, I had intentionally (wrongfully!) defined that variable, so all the libraries are not linked for all the programs (for example some programs don't need GSL, or some don't need CFITSIO). This was done very early on and I didn't know that there is no harm in having unused libraries in the list of libraries to link against: the linker will search the library and only use the parts that are needed.

The autoconf manual suggests using AC_SEARCH_LIBS instead of AC_CHECK_LIB, since it allows for searching a function in multiple libraries (for example in different operating systems). Also it will automatically add the library to the LIBS variable. A great consequence of this is that since LIBS is used in checking the subsequent libraries, if we start checking from the lowest level library to the highest, there will be no need to add linking flags in checking the libraries.

With all the links defined here, we can now remove the -lLIBRARY flags from AM_LDFLAGS in all the separate subdirectories. I will finish the implementation and if it compiles on Ubuntu, I will push it to master (and post a comment here).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 01 Jun 2016 01:59:07 PM UTC, comment #3: 

I can compile if AM_LDFLAGS is after astimgcrop_LDADD in the Makefile, but I don't know how to tell it to Automake

Mosè Giordano <giordano>
Group Member
Wed 01 Jun 2016 01:06:49 PM UTC, comment #2: 

Yes, that was my first guess too. But prior to reaching ImageCrop, Convolve is successfully built!

When you compare the AM_LDFLAGS on the Makefile.am of ImageCrop and Convolve, you see they are the same!

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 01 Jun 2016 01:01:59 PM UTC, comment #1: 

Strange, I don't have problems in Debian and I'd expect the same for Ubuntu.

I'll try to find an Ubuntu box to test with, for the moment I'd bet on wrong order of linking options.

Mosè Giordano <giordano>
Group Member
Wed 01 Jun 2016 12:58:28 PM UTC, original submission:  

I was looking around the internet and I found this reddit discussion with a linking error when install Gnuastro in Ubuntu:


Using Virtual Box, I installed Ubuntu 14.04 and this linking error does indeed come up when installing ImageCrop, no matter if I build GSL from source or if I use apt-get.

This is strange since GSL is successfully linked to in previous utilities and there is no problem. It also doesn't exist in our GNU/Linux distributions and also on Mac OS X.

Mohammad Akhlaghi <makhlaghi>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by giordano (Posted a comment)
  • -email is unavailable- added by makhlaghi (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-06-02 makhlaghi StatusConfirmed Fixed
        Assigned toNone makhlaghi
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code