Hide Forgot
Spec URL: will attach to this bug SRPM URL: other components of package can be found in Fedora git for unixODBC, mysql-connector-odbc, postgresql-odbc Description: The plan is to ship a parallel set of ODBC packages that conform to the modern interpretation of the ODBC ABI for 64-bit machines. See bug #497016 for background.
Created attachment 526734 [details] specfile for unixODBC64
Created attachment 526735 [details] mysql-connector-odbc64 specfile
Created attachment 526736 [details] postgresql-odbc64
Created attachment 526738 [details] documentation file required by unixODBC64.spec
Created attachment 526753 [details] updated odbcinst.ini for unixODBC64 (and unixODBC) This updated odbcinst.ini provides typical driver configurations for both unixODBC and unixODBC64. My intention is to have both unixODBC and unixODBC64 installing the identical file (as %config(noreplace)). This is a bit weird but doesn't seem to cause any problems in my testing.
I have some troubles with building postgresql-odbc64 package without unixODBC-libs installed (I don't think it is necessary, correct me if I'm wrong). I have now only unixODBC64 installed, but the thing is that configure script checks if libodbc.so is present, which is not, because I have only libodbc64.so. The following patches should fix this.
Created attachment 526799 [details] Patch to check for odbcinst64 in configure
Created attachment 526800 [details] patch to add "-lodbc64" in odbc_config utility postgresql-odbc uses "odbc_config --libs" utility during configuring, which prints "-L/usr/lib64 -lodbc" instead of "-L/usr/lib64 -lodbc64". This patch fixes odbc_config utility.
I also haven't manage to build mysql-connector-odbc successfully yet, since there is an error during configure: odbcinstw.c:114: error: conflicting types for 'SQLGetPrivateProfileStringW' /usr/include/odbcinst.h:345: error: previous declaration of 'SQLGetPrivateProfileStringW' was here odbcinstw.c:130: error: conflicting types for 'SQLInstallDriverExW' /usr/include/odbcinst.h:396: error: previous declaration of 'SQLInstallDriverExW' was here I suppose there is a similar issue like in postgresql-odbc, but not sure yet.
(In reply to comment #9) > I also haven't manage to build mysql-connector-odbc successfully yet, since > there is an error during configure: Hm, are you trying to build that with unixODBC-devel installed, rather than unixODBC64-devel? It builds just fine for me in a mock buildroot.
Created attachment 526808 [details] unixODBC64-2.2.14-1.el5.src.rpm
Created attachment 526809 [details] unixODBC-2.2.11-9.el5.src.rpm
Created attachment 526810 [details] postgresql-odbc64-09.00.0200-1.el5.src.rpm
Created attachment 526811 [details] mysql-connector-odbc64-5.1.8-1.el5.src.rpm
To possibly save you some time, here are the complete SRPMs I was testing yesterday.
(In reply to comment #10) > (In reply to comment #9) > > I also haven't manage to build mysql-connector-odbc successfully yet, since > > there is an error during configure: > > Hm, are you trying to build that with unixODBC-devel installed, rather than > unixODBC64-devel? It builds just fine for me in a mock buildroot. Sorry, I meant mysql-connector-odbc64. Thanks for the SRPMs, but mysql-connector-odbc64 and postgresql-odbc64 still don't build by me if I don't have unixODBC-libs installed. Have you tried to build the drivers without unixODBC-libs installed (only against unixODBC64-devel + unixODBC64-libs)?
(In reply to comment #16) > Have you tried to build the drivers without unixODBC-libs installed (only > against unixODBC64-devel + unixODBC64-libs)? Yeah, I'm fairly sure that that's how I've been building them ... are you doing this in a RHEL5 buildroot, or something newer?
(In reply to comment #17) > Yeah, I'm fairly sure that that's how I've been building them ... are you doing > this in a RHEL5 buildroot, or something newer? I'm doing it on RHEL-5 in VM. I'll try do it in mock.
Hm, right now mock is failing to work for me at all, but I certainly was able to build these things yesterday. I have to leave for an appointment for the rest of the evening, but if I'm not too tired when I get home, I'll take a closer look.
Created attachment 526819 [details] patch for mysql-connector-odbc64 Without this patch mysql-connector-odbc64 is not able to be built when only unixODBC64-devel and no unixODBC* package is installed. This change fixes it.
OK source files match upstream: OK sha256sum unixODBC-2.2.14.tar.gz* fea02f2f687f55d4056728a602846fafd0e12d99110986633fb80e1bf0e94da5 unixODBC-2.2.14.tar.gz fea02f2f687f55d4056728a602846fafd0e12d99110986633fb80e1bf0e94da5 unixODBC-2.2.14.tar.gz.orig OK sha256sum psqlodbc-09.00.0200.tar.gz* e71c8ecc18a9a3aa9bf3981a20a316ae1a0cd999a96e7567a70022650672fe31 psqlodbc-09.00.0200.tar.gz e71c8ecc18a9a3aa9bf3981a20a316ae1a0cd999a96e7567a70022650672fe31 psqlodbc-09.00.0200.tar.gz.orig N/A mysql-connector-odbc-5.1.9.tar.gz not available any more on the upstream website OK package meets naming and versioning guidelines OK specfile is properly named, is cleanly written and uses macros consistently. OK dist tag is present. OK license field matches the actual license. OK license is open source-compatible. License text included in package. N/A latest version is being packaged. Not intended. OK BuildRequires are proper. OK compiler flags are appropriate. BAD package builds in mock. unixODBC64 builds OK postgresql-odbc64 fails with error: checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. mysql-connector-odbc64 fails with error: odbcinstw.c:114: error: conflicting types for 'SQLGetPrivateProfileStringW' /usr/include/odbcinst.h:345: error: previous declaration of 'SQLGetPrivateProfileStringW' was here odbcinstw.c:130: error: conflicting types for 'SQLInstallDriverExW' /usr/include/odbcinst.h:396: error: previous declaration of 'SQLInstallDriverExW' was here odbcinstw.c:170: error: conflicting types for 'SQLValidDSNW' /usr/include/odbcinst.h:333: error: previous declaration of 'SQLValidDSNW' was here odbcinstw.c:185: error: conflicting types for 'SQLRemoveDSNFromIniW' /usr/include/odbcinst.h:332: error: previous declaration of 'SQLRemoveDSNFromIniW' was here odbcinstw.c:200: error: conflicting types for 'SQLWriteDSNToIniW' /usr/include/odbcinst.h:331: error: previous declaration of 'SQLWriteDSNToIniW' was here odbcinstw.c:222: error: conflicting types for 'SQLPostInstallerErrorW' /usr/include/odbcinst.h:377: error: previous declaration of 'SQLPostInstallerErrorW' was here odbcinstw.c:241: error: conflicting types for 'SQLRemoveDriverW' /usr/include/odbcinst.h:360: error: previous declaration of 'SQLRemoveDriverW' was here odbcinstw.c:258: error: conflicting types for 'SQLWritePrivateProfileStringW' /usr/include/odbcinst.h:338: error: previous declaration of 'SQLWritePrivateProfileStringW' was here make[1]: *** [odbcinstw.lo] Error 1 After I applied patches above, everything looks good. OK debuginfo package looks complete. NO rpmlint is silent. This is rpmlint run on packages pathed with fixes above: mysql-connector-odbc64.src:40: W: macro-in-comment %{SOURCE1} mysql-connector-odbc64.src:42: W: macro-in-comment %patch1 mysql-connector-odbc64.src: W: invalid-url Source0: mysql-connector-odbc-5.1.8.tar.gz mysql-connector-odbc64.x86_64: E: incorrect-fsf-address /usr/share/doc/mysql-connector-odbc64-5.1.8/LICENSE.gpl postgresql-odbc64.src: W: invalid-url Source0: psqlodbc-09.00.0200.tar.gz postgresql-odbc64.x86_64: E: invalid-soname /usr/lib64/psqlodbcw.so psqlodbcw.so postgresql-odbc64.x86_64: E: incorrect-fsf-address /usr/share/doc/postgresql-odbc64-09.00.0200/license.txt unixODBC64.src: W: spelling-error %description -l en_US unixODBC -> Unicode unixODBC64.src: W: spelling-error %description -l en_US mysql -> myself unixODBC64.src: W: spelling-error %description -l en_US postgresql -> postgraduate unixODBC64.x86_64: W: spelling-error %description -l en_US mysql -> myself unixODBC64.x86_64: W: spelling-error %description -l en_US postgresql -> postgraduate unixODBC64.x86_64: W: file-not-utf8 /usr/share/doc/unixODBC64-2.2.14/ChangeLog unixODBC64.x86_64: W: no-manual-page-for-binary odbcinst unixODBC64.x86_64: W: no-manual-page-for-binary dltest unixODBC64.x86_64: W: no-manual-page-for-binary isql unixODBC64.x86_64: W: no-manual-page-for-binary odbc_config unixODBC64.x86_64: W: no-manual-page-for-binary iusql unixODBC64-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/unixODBC-2.2.14/exe/odbc-config.c unixODBC64-devel.x86_64: W: spelling-error Summary(en_US) unixODBC -> Unicode unixODBC64-devel.x86_64: W: no-documentation unixODBC64-libs.x86_64: W: spelling-error Summary(en_US) unixODBC -> Unicode unixODBC64-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libodbcpsqlS64.so unixODBC64-libs.x86_64: E: incorrect-fsf-address /usr/share/doc/unixODBC64-libs-2.2.14/COPYING unixODBC64-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libodbc64.so unixODBC64-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libodbcinst64.so unixODBC64-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libodbcmyS64.so unixODBC64-libs.x86_64: E: zero-length /etc/odbc.ini 11 packages and 0 specfiles checked; 6 errors, 22 warnings. Notes for rpmlint: Only two names are spelled incorrectly in /usr/share/doc/unixODBC64-2.2.14/ChangeLog, nothing serious (Jürgen and Jon Kĺre Hellan). I suppose file /etc/odbc is empty intentionally. No errors/warnings seems to be serious. OK final provides and requires look sane. N/A %check is present and all tests pass. OK shared libraries are added to the regular linker search paths with proper scriptlets OK owns the directories it creates. OK doesn't own any directories it shouldn't. OK no duplicates in %files. OK file permissions are appropriate. OK correct scriptlets present. OK code, not content. OK documentation is small, so no -docs subpackage is necessary. OK %docs are not necessary for the proper functioning of the package. OK headers in -devel N/A pkgconfig files in -devel OK no libtool .la droppings. OK not a GUI app. OK obsoletes and provides of the obsoleted package are valid
(In reply to comment #18) > I'm doing it on RHEL-5 in VM. I'll try do it in mock. Btw, I had the same errors in mock.
Ohhhh ... I see the problem. I did not try to rebuild the driver packages after I added this stuff to unixODBC64.spec: # These libraries are commonly dlopen'd, so provide versionless symlinks. # To avoid conflicting with the unixODBC package, attach "64" to their names. # Also, to avoid having unixODBC64-devel conflict with unixODBC-libs, we # have to remove the versionless symlinks from the -devel package. for lib in libodbc.so libodbcinst.so libodbcpsqlS.so libodbcmyS.so do lib64=`echo $lib | sed 's/\.so/64.so/'` echo "%{_libdir}/$lib64" >> libs-so-list pushd $RPM_BUILD_ROOT%{_libdir} ln -s ${lib}.*.* $lib64 rm ${lib} popd grep -v "/$lib$" devel-so-list > devel-so-list.x mv -f devel-so-list.x devel-so-list done specifically the part about removing the non-"64" links from unixODBC64-devel. I wonder whether we really ought to do the above for libodbc.so and libodbcinst.so. If we do, then ODBC driver packages will have to be tweaked as per your patches for anything that needs to be rebuilt against unixODBC64 --- which seems like mostly just an annoyance, since you've already had to declare your preference by choosing whether to build against unixODBC-devel or unixODBC64-devel. Of the libraries called out above, I know that libodbcpsqlS.so and libodbcmyS.so actually need to be dlopen'ed under those names because they're called via entries in /etc/odbcinst.ini. I am not so sure that libodbc.so and libodbcinst.so really need this. libodbcinst, at least, seems to get hard-linked into ODBC drivers when they are built. I'm not entirely sure about how libodbc.so gets called. This could probably use a bit more investigation as to what's the least unpleasant way to do it. I'm too tired to do much in that line tonight. But in any case it doesn't seem to me to be grounds for blocking the package from RHEL-5 ... it's something that we can tweak during beta testing.
(In reply to comment #23) > Of the libraries called out above, I know that libodbcpsqlS.so and > libodbcmyS.so actually need to be dlopen'ed under those names because they're > called via entries in /etc/odbcinst.ini. I am not so sure that libodbc.so and > libodbcinst.so really need this. libodbcinst, at least, seems to get > hard-linked into ODBC drivers when they are built. I'm not entirely sure about > how libodbc.so gets called. I'm not sure if I get your point -- if we won't rename libraries to libodbc64.so and libodbcinst64.so, they'd conflict with unixODBC-libs. If we won't use libodbcinst.so and libodbc.so symlinks at all, we'll have to patch drivers and use dlopen, which brings us to the present situation -- no pros from my POV. > But in any case it doesn't seem to me to be grounds for blocking the package from > RHEL-5 ... it's something that we can tweak during beta testing. As soon as packages are able to build in mock, the review can be considered approved.
(In reply to comment #24) > I'm not sure if I get your point -- if we won't rename libraries to > libodbc64.so and libodbcinst64.so, they'd conflict with unixODBC-libs. Well, so far as libodbcinst is concerned, we don't have to put it in unixODBC-libs. I had done that for consistency with the Fedora packaging (cf bug #204882), but in RHEL-5 it's always been in the -devel subpackage. The problems you turned up convince me that we should just leave it in the -devel subpackage, ie, 204882 becomes a WONTFIX for RHEL-5. We do still need to do something about libodbc, unless we're willing to move that symlink over to the devel package. I'm unsure if we could get away with that, or if patching as you suggest is the better solution. > As soon as packages are able to build in mock, the review can be considered > approved. Fair enough, I'll work on that right now.
(In reply to comment #25) > We do still need to do something about libodbc, unless we're willing to move > that symlink over to the devel package. I'm unsure if we could get away with > that, or if patching as you suggest is the better solution. A bit of research located bug #72653, which says that we need to keep that symlink in the base (now -libs) package. I'll go ahead with your patches for -lodbc.
OK, I moved libodbcinst.so back to the -devel RPMs, and applied your patches for -lodbc versus -lodbc64. I get successful builds now both in mock and on a RHEL5 test machine. Is it worth attaching the corrected SRPMs to this bug?
(In reply to comment #27) > OK, I moved libodbcinst.so back to the -devel RPMs, and applied your patches > for -lodbc versus -lodbc64. I get successful builds now both in mock and on a > RHEL5 test machine. Is it worth attaching the corrected SRPMs to this bug? Not needed for me, the change is obvious and it works for me too. Approved.