-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike,
You are exactly correct.
With regards
Kamesh Jayachandran
C. Michael Pilato wrote:
> 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?
>>>
>>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJv64C3WHvyO0YTCwRAg23AKCDZiXac57GTskCuLq0cBJ/ifb0mQCfZGhn
zHFahsQkrR4Pd4F6eMyC07A=
=49Ru
-----END PGP SIGNATURE-----
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1341331
Received on 2009-03-17 15:03:55 CET