Kern Sibbald schrieb:
> On Thursday 30 July 2009 23:41:28 Timo Neuvonen wrote:
>> "Kern Sibbald" <k...@sibbald.com> kirjoitti viestissä
>> news:200907302233.19300.k...@sibbald.com...
>>
>>> On Thursday 30 July 2009 22:24:25 Scott Barninger wrote:
>>>> On Wednesday 29 July 2009 08:21:50 am Timo Neuvonen wrote:
>>>>> I tried to build 3.0.2 binary rpms with the following script, on
>>>>> CentOS 5.3 x86_64
>>>>>
>>>>> #!/bin/bash
>>>>> rpmbuild --rebuild \
>>>>> --define "build_centos5 1" \
>>>>> --define "build_x86_64 1" \
>>>>> --define "build_mysql5 1" \
>>>>> --define "build_python 1" \
>>>>> --define "nobuild_gconsole 1" \
>>>>> --define "contrib_packager Timo Neuvonen <t...@tee-en.net>" \
>>>>> bacula-3.0.2-1.src.rpm
>>>>>
>>>>> This ends up with the following:
>>>>>
>>>>>
>>>>> RPM build errors:
>>>>> InstallSourcePackage: Header V3 DSA signature: NOKEY, key ID
>>>>> b90d278f
>>>>> user sbarn does not exist - using root
>>>>> user sbarn does not exist - using root
>>>>> user sbarn does not exist - using root
>>>>> user sbarn does not exist - using root
>>>>> user sbarn does not exist - using root
>>>>> user sbarn does not exist - using root
>>>>> user sbarn does not exist - using root
>>>>> File not found: /var/tmp/bacula-root/etc/bacula/bacula-dir.conf
>>>>> File not found: /var/tmp/bacula-root/etc/bacula/bacula-fd.conf
>>>>> File not found: /var/tmp/bacula-root/usr/lib64/bacula/query.sql
>>>>> File not found: /var/tmp/bacula-root/usr/sbin/bacula-dir
>>>>> File not found: /var/tmp/bacula-root/usr/sbin/bacula-fd
>>>>> File not found: /var/tmp/bacula-root/etc/bacula/bacula-fd.conf
>>>>> File not found: /var/tmp/bacula-root/usr/sbin/bacula-fd
>>>>> [t...@garfield rpm-build]$
>>>>>
>>>>>
>>>>>
>>>>> The OS is up-to-date, and has been able to build previous versions
>>>>> (including 3.0.1) of Bacula. On my another CentOS 5.3 system which is
>>>>> x86, the build goes nicely, and the resulting binaries also seem to
>>>>> work.
>>>>> So, maybe this is something x86_64 related?
>>>>>
>>>>>
>>>>> Regards,
>>>>> Timo
>>>> Sounds like an error compiling. Can you provide other detail?
>> I got during compiling exactly the same errors that Andreas Piesk already
>> quoted in his message:
>>
>> job.o: In function `storage_cmd':
>> /usr/src/redhat/BUILD/bacula-3.0.2/src/filed/job.c:1402: undefined
>> reference to `BSOCK::set_source_address(dlist*)'
>> collect2: ld returned 1 exit status
>>
>>> I don't seem to have any problem building on RHEL 5.3 x86_64, so I
>>> imagine they may have modified the source or somehow gotten a bad source
>>> (which doesn't make much sense).
>> I'd made no (intentional) alterations to the source. I also downloaded the
>> source package again, it does not differ from the originally loaded srpm.
>> The same error too, until... dropping the (deprecated?)
>> --define "build_x86_64 1" \
>> from the build script finally made it. And yes, it seems at least to place
>> the binaries under directory
>> /usr/src/redhat/RPMS/x86_64/
>> so they obviously are built as 64 bit even without the define.
>>
>> So, at least in my CentOS 5.3 system using
>> --define "build_x86_64 1"
>> makes the build to fail.
>
> Strange. I see nothing in the spec file that would make this fail. Oh well,
> at least the problem has a workaround.
>
if i rebuild with 3.0.2 installed, the build succeeds, no matter how
build_x86_64 is set.
i think the problem is caused by the order of the library directories.
Linking bacula-fd ...
/usr/src/redhat/BUILD/bacula-3.0.2/libtool --silent --tag=CXX
--mode=link /usr/bin/g++ -L/usr/lib64 -L../lib -L../findlib -o ...
with build_x86_64 set -L/usr/lib64 comes _before_ -L../lib -L../findlib,
so it tries to link in libraries from -L/usr/lib64 first, which fails
with installed libraries from previous releases because they lack
BSOCK::set_source_address(dlist*).
i guess setting version-info to release version 3:0:2 instead of 1:0:0
solves the problem.
i think build_x86_64 was necessary for building bat on x86_64 but by
using pkgconfig to get paths it is no longer. from the spec file:
%if %{bat}
export QTDIR=$(pkg-config --variable=prefix QtCore)
export QTINC=$(pkg-config --variable=includedir QtCore)
export QTLIB=$(pkg-config --variable=libdir QtCore)
export PATH=${QTDIR}/bin/:${PATH}
%endif
...
# Red Hat's 64 bit installation of QT4 appears to be broken so:
%define qt_path 0
%if %{rhel5} || %{centos5} || %{sl5}
%define qt_path 1
%endif
%if %{bat} && %{qt_path} && %{x86_64}
export PATH=/usr/lib64/qt4/bin/:$PATH
export QTDIR=/usr/lib64/qt4/
export QTINC=/usr/lib64/qt4/include/
export QTLIB=/usr/lib64/qt4/
%endif
IMHO the latter can be removed because the first takes care of QT paths.
regards,
-ap
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
