Bug 475411

I've committed the version update, suitesparse-3.2 should appear in rawhide tomorrow.

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?

Is this with the just built suitesparse-3.2?

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.

(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.

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.

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.

Check out the build at http://koji.fedoraproject.org/koji/taskinfo?taskID=1005957 . Let me know if it works OK for you.

"-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.

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?

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.

(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.

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.

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.

(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'.

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?

(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.

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.

(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.

(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.

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)

(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.

(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.

(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)

Tried running 'readelf --syms /usr/lib64/libcholmod.so.1.7.0 | grep UND'?

(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'?

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.

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?

(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.

This seems fixed to me, I'd be ok closing it.

+1

Since we got no objections, I'm closing the bug.

Thank you Deji, for taking care of this.

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)?

The fix indeed wasn't made in F-10 nor F-9.

Well, I'm going to disregard F-9, but I'll submit it to F-10.

Oh, wait this isn't my package. Disregard the previous comment.

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.

This is still a bug as best I know.

Changed the Version from 9 to 10.

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?

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

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

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.