Bug 475411 - suitesparse is incorrectly linked and has undefined symbols
suitesparse is incorrectly linked and has undefined symbols
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: suitesparse (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Quentin Spencer
Fedora Extras Quality Assurance
http://www.cise.ufl.edu/research/spar...
: Reopened
Depends On:
Blocks: 466717
  Show dependency treegraph
 
Reported: 2008-12-08 23:29 EST by Orcan Ogetbil
Modified: 2009-08-07 00:56 EDT (History)
5 users (show)

See Also:
Fixed In Version: 3.1.0-2.fc10.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-07 00:56:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Orcan Ogetbil 2008-12-08 23:29:08 EST
Description of problem:
Current suitsparse version is outdated. Upstream released a new version since the last update.

Actual results:
version 3.1 in Fedora

Expected results:
version 3.2 in Fedora
Comment 1 Deji Akingunola 2008-12-16 13:17:52 EST
I've committed the version update, suitesparse-3.2 should appear in rawhide tomorrow.
Comment 2 Orcan Ogetbil 2008-12-16 13:51:29 EST
If we do a:
   python -c "from ctypes import *; cdll.LoadLibrary('libcholmod.so.1')"

it gives us the following error:
   OSError: /usr/lib64/libcholmod.so.1: undefined symbol: amd_printf

I think this is a problem of suitesparse. Is this a packaging bug or an upstream one?
Comment 3 Deji Akingunola 2008-12-16 13:58:20 EST
Is this with the just built suitesparse-3.2?
Comment 4 Orcan Ogetbil 2008-12-16 14:09:36 EST
yes, I pulled it from koji and tried it with that.

The bug was also present in 3.1. I thought I should wait for the update before I report it. But with 3.2, the bug is still there.
Comment 5 Deji Akingunola 2008-12-17 10:44:08 EST
(In reply to comment #4)
> yes, I pulled it from koji and tried it with that.
> 
> The bug was also present in 3.1. I thought I should wait for the update before
> I report it. But with 3.2, the bug is still there.

This is likely an upstream bug, please report it there.
Comment 6 Orcan Ogetbil 2008-12-17 13:33:04 EST
OK, I found the problem. The libraries are linked improperly:
        $ ldd /usr/lib64/libcholmod.so
        linux-vdso.so.1 =>  (0x00007ffff9dff000)
        libc.so.6 => /lib64/libc.so.6 (0x00000000003ed000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003dd3600000)
but that's it. This list should be a bit longer normally.

Also the other libraries in this package have the same flaw. If you are not sure about what libraries to link, you can cheat by looking at the Ubuntu patches.
Comment 7 Conrad Meyer 2008-12-17 18:42:17 EST
Alternatively:
$ readelf --syms /usr/lib64/libcholmod.so | grep amd_printf
     3: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND amd_printf
    16: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND colamd_printf

Re-opening because this is the bug we actually need fixed. Changing title to be more clear. Rpmlint *should* have caught undefined symbols like this, but maybe the problem was introduced post-review.
Comment 8 Deji Akingunola 2008-12-18 02:55:21 EST
Check out the build at http://koji.fedoraproject.org/koji/taskinfo?taskID=1005957 . Let me know if it works OK for you.
Comment 9 Orcan Ogetbil 2008-12-18 03:29:13 EST
"-lcblas -lclapack"

Do you mean:
"-lblas -llapack" ? Things work with this change (tested).

There is no clapack in Fedora. Also some of the other libraries (as far as I can tell UMFPACK, maybe others too) need proper linking.
Comment 10 Conrad Meyer 2008-12-18 06:39:01 EST
The koji build definitely doesn't work ('readelf --syms libcholdmod.so | grep  UND' still contains the symbols we need). Orcan: Does it contain amd_printf in your rebuild?
Comment 11 Orcan Ogetbil 2008-12-18 16:38:45 EST
Conrad,
If you do the above change in the SPEC file, you'll have amd_printf, and cvxopt works. But other than this, the other libraries (such as UMFPACK) need linked properly too.
Comment 12 Deji Akingunola 2008-12-20 23:21:04 EST
(In reply to comment #10)
> The koji build definitely doesn't work ('readelf --syms libcholdmod.so | grep 
> UND' still contains the symbols we need).
>
What do you mean by the above? that's sentence is very unclear. BTW, there's an obvious typo there, try again with libcholdmod.so -> libcholmod.so.

@ Orcan,
There's a new scratch build at  http://koji.fedoraproject.org/koji/taskinfo?taskID=1012882 , can you test it, and let me know if it works for you.
Comment 13 Orcan Ogetbil 2008-12-21 03:48:09 EST
It builds with mock using fedora-rawhide-x86_64 but it fails to build for fedora-10-x86_64 with the error message:
   ld: cannot find -lclapack
I tried to install the fc11 RPM on Fedora 10. It says:
   error: Failed dependencies:
        libclapack.so.3()(64bit) is needed by suitesparse-3.2.0-4.fc11.x86_64

So I couldn't test it.
Comment 14 Orcan Ogetbil 2008-12-21 04:05:52 EST
OK, I installed the rawhide version of atlas, which has clapack. Now I get the error:
   /usr/lib64/atlas/liblapack.so.3: undefined symbol: cblas_zswap
It looks like there's a problem with the atlas package now.
Comment 15 Deji Akingunola 2008-12-21 08:00:01 EST
(In reply to comment #14)
> OK, I installed the rawhide version of atlas, which has clapack. Now I get the
> error:
>    /usr/lib64/atlas/liblapack.so.3: undefined symbol: cblas_zswap
> It looks like there's a problem with the atlas package now.
What were you doing when you got the undefined symbol message? Anyways, I think you need to link your binary with 'cblas'; sth like '-L/usr/lib64/atlas -lcblas'.
Comment 16 Orcan Ogetbil 2008-12-21 11:34:38 EST
You can use the same command as before to get the error:
   $python -c "from ctypes import *; cdll.LoadLibrary('liblapack.so.3')"
   
I don't have a binary to link with. Are you talking about the liblapack.so.3 binary?
Comment 17 Deji Akingunola 2008-12-21 22:47:25 EST
(In reply to comment #16)
> You can use the same command as before to get the error:
>    $python -c "from ctypes import *; cdll.LoadLibrary('liblapack.so.3')"
> 
I've fixed this in atlas-3.8.2-5, which will hopefully appear in rawhide tomorrow (you can also grab it from http://koji.fedoraproject.org/koji/buildinfo?buildID=75911). Thanks for pointing out the issue.
Comment 18 Orcan Ogetbil 2008-12-22 00:55:16 EST
Everything works now. (One thing I noticed is, the $RPM_OPT_FLAGS are not passed to the compiler during the compilation of atlas.)

Will you push these packages to Fedora 10 too? They are still broken in the stable repos.
Comment 19 Deji Akingunola 2008-12-22 08:18:50 EST
(In reply to comment #18)
> Everything works now. (One thing I noticed is, the $RPM_OPT_FLAGS are not
> passed to the compiler during the compilation of atlas.)
> 
> Will you push these packages to Fedora 10 too? They are still broken in the
> stable repos.

I will wait for it to settle down in rawhide for a while (2 weeks ?) before pushing them to F-10. A couple of other packages depends on them, so the update have to be coordinated.
Comment 20 Conrad Meyer 2008-12-22 15:45:02 EST
(In reply to comment #12)
> (In reply to comment #10)
> > The koji build definitely doesn't work ('readelf --syms libcholdmod.so | grep 
> > UND' still contains the symbols we need).
> >
> What do you mean by the above? that's sentence is very unclear. BTW, there's an
> obvious typo there, try again with libcholdmod.so -> libcholmod.so.

It's pretty clear. That build still didn't work -- for example, running 'readelf --syms libcholmod.so | grep UND' (which shows undefined symbols) still shows symbols we need, such as amd_prinf.

readelf doesn't show anything for non-existent files, libcholdmod.so was just a transcription error.
Comment 21 Rex Dieter 2009-01-09 15:54:53 EST
ditto here too, a multitude of undefined symbols:

$ ldd -r /usr/lib64/libcholmod.so
undefined symbol: amd_printf    (/usr/lib64/libcholmod.so) 
        linux-vdso.so.1 =>  (0x00007fffc19fe000)           
        libc.so.6 => /lib64/libc.so.6 (0x00000000003ed000) 
        /lib64/ld-linux-x86-64.so.2 (0x00007f2bb9955000)   
undefined symbol: amd_calloc    (/usr/lib64/libcholmod.so) 
undefined symbol: amd_free      (/usr/lib64/libcholmod.so) 
undefined symbol: colamd_printf (/usr/lib64/libcholmod.so) 
undefined symbol: amd_realloc   (/usr/lib64/libcholmod.so)
undefined symbol: amd_malloc    (/usr/lib64/libcholmod.so)
undefined symbol: sqrt  (/usr/lib64/libcholmod.so)
undefined symbol: zherk_        (/usr/lib64/libcholmod.so)
undefined symbol: dgemm_        (/usr/lib64/libcholmod.so)
undefined symbol: colamd_recommended    (/usr/lib64/libcholmod.so)
undefined symbol: dtrsv_        (/usr/lib64/libcholmod.so)
undefined symbol: colamd_l      (/usr/lib64/libcholmod.so)
undefined symbol: zgemm_        (/usr/lib64/libcholmod.so)
undefined symbol: amd_2 (/usr/lib64/libcholmod.so)
undefined symbol: ztrsv_        (/usr/lib64/libcholmod.so)
undefined symbol: colamd        (/usr/lib64/libcholmod.so)
undefined symbol: zgemv_        (/usr/lib64/libcholmod.so)
undefined symbol: dsyrk_        (/usr/lib64/libcholmod.so)
undefined symbol: colamd_l_set_defaults (/usr/lib64/libcholmod.so)
undefined symbol: dtrsm_        (/usr/lib64/libcholmod.so)
undefined symbol: dpotrf_       (/usr/lib64/libcholmod.so)
undefined symbol: colamd_set_defaults   (/usr/lib64/libcholmod.so)
undefined symbol: zpotrf_       (/usr/lib64/libcholmod.so)
undefined symbol: amd_l2        (/usr/lib64/libcholmod.so)
undefined symbol: colamd_l_recommended  (/usr/lib64/libcholmod.so)
undefined symbol: dgemv_        (/usr/lib64/libcholmod.so)
undefined symbol: ztrsm_        (/usr/lib64/libcholmod.so)
Comment 22 Deji Akingunola 2009-01-26 20:39:53 EST
(In reply to comment #21)
> ditto here too, a multitude of undefined symbols:
> 
I'm sorry for not being able to get out the fix this for F10 until now (fixed package has been in rawhide for a while).
Can you please test the scratch build at http://koji.fedoraproject.org/koji/taskinfo?taskID=1084907 and let me know if it resolves the undefined symbols?
Thanks.
Comment 23 Conrad Meyer 2009-01-29 11:53:44 EST
(In reply to comment #22)
> (In reply to comment #21)
> > ditto here too, a multitude of undefined symbols:
> > 
> I'm sorry for not being able to get out the fix this for F10 until now (fixed
> package has been in rawhide for a while).
> Can you please test the scratch build at
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1084907 and let me know if
> it resolves the undefined symbols?
> Thanks.

$ readelf --syms libcholmod.so.1.7.0 | grep UND

Still has a lot (50) of undefined symbols.
Comment 24 Deji Akingunola 2009-01-29 12:40:28 EST
(In reply to comment #23)
> (In reply to comment #22)
> > (In reply to comment #21)
> > > ditto here too, a multitude of undefined symbols:
> > > 
> > I'm sorry for not being able to get out the fix this for F10 until now (fixed
> > package has been in rawhide for a while).
> > Can you please test the scratch build at
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1084907 and let me know if
> > it resolves the undefined symbols?
> > Thanks.
> 
> $ readelf --syms libcholmod.so.1.7.0 | grep UND
> 
> Still has a lot (50) of undefined symbols.

[deji@logos ~]$ ldd -r /usr/lib64/libcholmod.so.1.7.0
	linux-vdso.so.1 =>  (0x00007fff9a1fe000)
	libblas.so.3 => /usr/lib64/libblas.so.3 (0x00000000003ed000)
	liblapack.so.3 => /usr/lib64/liblapack.so.3 (0x0000000000645000)
	libamd.so.2 => /usr/lib64/libamd.so.2 (0x0000000000dd7000)
	libcamd.so.2 => /usr/lib64/libcamd.so.2 (0x0000000000fdf000)
	libcolamd.so.2 => /usr/lib64/libcolamd.so.2 (0x0000000037603000)
	libccolamd.so.2 => /usr/lib64/libccolamd.so.2 (0x00000000011e8000)
	libm.so.6 => /lib64/libm.so.6 (0x00000000013f1000)
	libc.so.6 => /lib64/libc.so.6 (0x0000000001676000)
	libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00000000019e8000)
	/lib64/ld-linux-x86-64.so.2 (0x00000035e5400000)
Comment 25 Conrad Meyer 2009-01-29 12:44:01 EST
Tried running 'readelf --syms /usr/lib64/libcholmod.so.1.7.0 | grep UND'?
Comment 26 Deji Akingunola 2009-01-29 12:52:49 EST
(In reply to comment #25)
> Tried running 'readelf --syms /usr/lib64/libcholmod.so.1.7.0 | grep UND'?

That doesn't imply the dependent libraries are not correctly linked. Why not try running 'ldd -r /usr/lib64/libcholmod.so | grep undefined'?
Comment 27 Conrad Meyer 2009-01-29 12:59:00 EST
I noticed that did not say anything already. So you are saying other libraries provide those symbols? In that case I think this is fixed.
Comment 28 Orcan Ogetbil 2009-01-29 13:08:12 EST
Deji, I think it is OK now. Why don't use submit your build script (which grew big by now) upstream so that more people can benefit from it?
Comment 29 Deji Akingunola 2009-01-29 13:37:44 EST
(In reply to comment #28)
> Deji, I think it is OK now. Why don't use submit your build script (which grew
> big by now) upstream so that more people can benefit from it?
Yeah I would have done that, but the upstream build system is not designed in a way the changes here would be useful to it. It (upstream) doesn't build shared libraries.
Comment 30 Conrad Meyer 2009-02-16 01:22:54 EST
This seems fixed to me, I'd be ok closing it.
Comment 31 Orcan Ogetbil 2009-02-16 01:51:50 EST
+1
Comment 32 Orcan Ogetbil 2009-02-18 13:06:44 EST
Since we got no objections, I'm closing the bug.

Thank you Deji, for taking care of this.
Comment 33 Rex Dieter 2009-06-22 12:03:18 EDT
fyi, this is still broken for F-10's current
suitesparse-devel-3.1.0-1.fc9
I was under the impression from comment #22, that F-10 would get fixed (too)?
Comment 34 Kevin Kofler 2009-06-22 12:53:07 EDT
The fix indeed wasn't made in F-10 nor F-9.
Comment 35 Conrad Meyer 2009-07-05 17:24:45 EDT
Well, I'm going to disregard F-9, but I'll submit it to F-10.
Comment 36 Conrad Meyer 2009-07-05 17:25:22 EDT
Oh, wait this isn't my package. Disregard the previous comment.
Comment 37 Bug Zapper 2009-07-14 14:17:03 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 38 Conrad Meyer 2009-07-14 14:53:53 EDT
This is still a bug as best I know.
Comment 39 Orcan Ogetbil 2009-07-15 02:56:32 EDT
Changed the Version from 9 to 10.
Comment 40 Deji Akingunola 2009-07-15 09:40:19 EDT
Fixed for F-10 with http://koji.fedoraproject.org/koji/taskinfo?taskID=1475727 . Can someone still on F-10 please confirm the above build is OK?
Comment 41 Fedora Update System 2009-07-23 14:33:45 EDT
suitesparse-3.1.0-2.fc10.1 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/suitesparse-3.1.0-2.fc10.1
Comment 42 Fedora Update System 2009-07-24 15:42:54 EDT
suitesparse-3.1.0-2.fc10.1 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update suitesparse'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-8001
Comment 43 Fedora Update System 2009-08-07 00:56:38 EDT
suitesparse-3.1.0-2.fc10.1 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.