Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: xtide - Calculate tide all over the world
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211626
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2006-10-21 10:52 EST ------- Well, before fixing this...
(In reply to comment #6)
It seems to me that it should be (with 0 instead of 1) %define libtcd_rel 0.%{fedora_rel} %define tcdutils_rel 0.%{fedora_rel}.date%{tcdutils_date2}
Well, I have been troubled with versioning. Usually your proposition is appropriate. However, "0." means (in fedora) "this is a pre or beta version" and * by libtcd.html, xtide src includes the "formal" (what I mean is not pre) 2.1.3 version. * for tcdutils, this is actually not pre version.
For libtcd instead of export CC="gcc `rpm --eval %%optflags` -DCOMPAT114" there should be something along %{__make} %{?_smp_mflags} \ OPTFLAGS="$RPM_OPT_FLAGS -DCOMPAT114" \ ......
For xtide -L/usr/lib shouldn't be there, it is allready on the linker path. (and anyway it should be -L%{_libdir}) -L./libtcd is certainly unneeded in extracxxflags
`rpm --eval %%optflags` should be replaced by %{optflags}, rpm shouldn't be called explicitely.
The /sbin/ldconfig $(pwd)/libtcd || : is very dubious. In my opinion it shouldn't be there.
I thought that, however, without this I get:
+ LD_LIBRARY_PATH=/home/tasaka1/rpmbuild/BUILD/xtide-2.9dev/libtcd + ./tcd-utils/build_tide_db harmonics-2004-06-14.tcd harmonics-2004-06-14.txt ./tcd-utils/build_tide_db: error while loading shared libraries: libtcd.so.2: cannot open shared object file: No such file or directory
You should use consistently %optflags and $RPM_BUILD_ROOT.
Okay, I will fix.
I propose the following for tcd-utils: %{__make} %{?_smp_mflags} \ CXXFLAGS="$RPM_OPT_FLAGS -I../libtcd -DCOMPAT114" \ CFLAGS="$RPM_OPT_FLAGS -I../libtcd -DCOMPAT114" \ LDFLAGS="-L../libtcd" together with the modified tcd-utils-1.3.7-shared.patch I'll attach, which adds LDFLAGS.
Okay, I will check it later.
I don't see why the somajor/minor/ver should be different from 0.0.0.
Umm, upstream has released libtcd version 1, which is API imcompatible with version 2. Through version 2 libctd seems API compatible. So I want to have SOMAJOR number 2 (and others similar).
How do you think of soname versioning?
(In reply to comment #8)
# local user fails on writing ld.so.cache file /sbin/ldconfig $RPM_BUILD_ROOT%{_libdir} || :
Um, no. <snip> The original suggestion in bug 211623 was to run ldconfig with option -n to ...
Okay. I will fix this.
------------------------------------------------------------------------- In short:
Well, before fixing this, will you tell me how do you think of A. libtcd and tcd-utils release numbering (0<->1) B. libtcd.so share object loading problem C. soname versioning ?