Re: Trouble building 1.6.0-rc3 against Berkeley DB on Solaris

I think Kamesh determined the problem. (Kamesh, please correct me if I'm
wrong.)

configure looks for a "suitable grep", but the criteria is simply "supports
long lines" and "supports the -e argument". Our buildstuffs expect grep to
have support for the -o argument, too, though. Our Solaris build
environment has both Solaris grep and GNU grep, but Solaris grep (which
doesn't support -o) was getting chosen by configure.

C. Michael Pilato wrote:
> By the way, all the ${TARGETDIR} instances in the lines posted should be
> __BUILDDIR__. I goofed my attempted at purging long paths.
>
> C. Michael Pilato wrote:
>> Hey, folks. I recently upgraded our CollabNet Enterprise Edition software
>> to Subversion 1.6.0-rc3 (in anticipation of releasing with 1.6.0-final), but
>> we've run into some problems with our Solaris build being unable to detect
>> Berkeley DB. We build basically the same way on both Solaris and Linux, and
>> of course were building 1.5.x against Berkeley DB just fine. But the
>> upgrade to 1.6.0-rc3 broke something. Here are the compilation commands
>> that configure is running:
>>
>> On Linux:
>>
>> ...
>> configure:23416: checking for availability of Berkeley DB
>> configure:23499: gcc -o conftest -g -O2 -pthread -D_LARGEFILE64_SOURCE \
>> -DNE_LFS -I__BUILDDIR__/apache-22/include/i386-redhat-5 -I__BUILDDIR__/be\
>> rkeley-db/platform/i386-redhat-5/berkeley-db/include -I__BUILDDIR__/apach\
>> e-22/include/i386-redhat-5 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEF\
>> ILE64_SOURCE -I__BUILDDIR__/apache-22/include/i386-redhat-5 -I${TARGETD\
>> IR}/apache-22/include/i386-redhat-5 -I__BUILDDIR__/berkeley-db/platform/i3\
>> 86-redhat-5/berkeley-db/include -L__BUILDDIR__/apache-22/lib/i386-redhat-5\
>> /apache -L__BUILDDIR__/berkeley-db/lib/i386-redhat-5 conftest.c -L${TA\
>> RGETDIR}/berkeley-db/lib/i386-redhat-5 -ldb-4.7 >&5
>> ...
>>
>> On Solaris:
>>
>> ...
>> configure:23416: checking for availability of Berkeley DB
>> configure:23499: gcc -o conftest -g -O2 -D_LARGEFILE64_SOURCE -DNE_LFS \
>> -I__BUILDDIR__/apache-22/include/sparc-sunos-5.10 -I__BUILDDIR__/berkeley\
>> -db/platform/sparc-sunos-5.10/berkeley-db/include -I__BUILDDIR__/apache-\
>> 22/include/sparc-sunos-5.10 -DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS -D_R\
>> EENTRANT -D_LARGEFILE64_SOURCE -I__BUILDDIR__/apache-22/include/sparc-sun\
>> os-5.10 -I__BUILDDIR__/apache-22/include/sparc-sunos-5.10 -I__BUILDDIR__\
>> /berkeley-db/platform/sparc-sunos-5.10/berkeley-db/include -L__BUILDDIR__\
>> /apache-22/lib/sparc-sunos-5.10/apache -L__BUILDDIR__/berkeley-db/lib/s\
>> parc-sunos-5.10 conftest.c -L__BUILDDIR__/berkeley-db/lib/sparc-sunos-5.1\
>> 0 -lsocket -lpthread -L/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.10/3.4.2 -\
>> lgcc >&5
>> ...
>>
>> Solaris build fails for an unresolved symbol "db_version".
>>
>> Of interest (to me, and hopefully to others) is that on Solaris, the
>> compilation command that configure uses doesn't carry a -ldb* flag, whereas
>> on Linux it does. apu-1-config --libs *does* print " -ldb-4.7 -lexpat
>> -liconv" on that platform (and " -ldb-4.7 -lexpat" on Linux), but it isn't
>> present in the test.
>>
>> I see the Arfrever did some work around these parts recently, so I'm sorta
>> kinda hoping this will ring a bell for him.
>>
>> Arfrever?
>>
>
>

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1341326