On Wed, Mar 2, 2016 at 10:20 PM, Wietse Venema <wie...@porcupine.org> wrote:
> Brett @Google:
> > Hello,
> >
> > I am upgrading 3.0.x to 3.1 it seems the build process has changed, there
> > are a few issues at least on solaris, maybe due to the dual 32/64 bit
> > library formats when compared to Linux.
> >
> > (running on SunOS server 5.10 Generic_150400-29 sun4v sparc sun4v)
>
> The chances that I'll be doing tests on sparc are pretty-much zero.
> I have some VMs for Intel lying around with 5.10 from various
> vintages but they come with gcc and most are 32bit.
>
The sun compiler is now free, but I think the problem si really an OS
where there are both 64 or 32 bit models available. If there is only one
model, then the compile options for the tests will match the OS library
model.
> > 1. Is seems to be no longer possible to have a different location for the
> > berkeley db include or lib directories. makedefs seems to just try one
> set
> > of assumptions about the base OS, and that you are using gcc, and gives
> up
> > returning -DNO_DB. makedefs does not even try to run a actual test, it
> > seems. but like the problem below, if it is running a 32 bit test, it
> wont
> > link with a 64 bit library
>
> The build has not changed between 3.0 and 3.1 (it changed a lot
> between 2.x and 3.x).
>
Thats not entirely true, the build has changed at least for libicu
(comparing 3.0.3 to 3.1), makedefs now explicitly uses ${CC-gcc}
< ${CC} -o makedefs.test makedefs.test.c $icu_cppflags \
< $icu_ldflags >/dev/null 2>&1
< if LD_LIBRARY_PATH=/usr/local/server-libs/lib
./makedefs.test 2>/dev/null ; then
< CCARGS="$CCARGS $icu_cppflags"
< SYSLIBS="$SYSLIBS $icu_ldflags"
---
> ${CC-gcc} -o makedefs.test makedefs.test.c
-I/usr/local/include \
> -L/usr/local/lib -licuuc >/dev/null 2>&1
> if ./makedefs.test 2>/dev/null ; then
> SYSLIBS="$SYSLIBS -L/usr/local/lib -licuuc"
But using cc or gcc, the 32/64 bit problem would still occur.. they act the
same.
> Have you tried "make makefiles "CC=whatever -m64" and have it pick
> up 64-bit libraries? I don't think I should hard-code your 32/64bit
> preferences in makedefs.
>
No, the hard coding was not an actual option being suggested, it was just
part of my diagnosis process.
Should makedefs compile tests include CCARGS, as that does contains the
right option ?
Edit: The problem seemed specifically around having enabled shared
libraries enabled, static linking with the same options in a single
AUXLIBS, and shared=no, works fine, likely shared libraries on solaris are
just broken, it seems.
Likely they have been always broken, turning it on shared libraries on an
unsupported shared library platform probably "caused" the problem. But I
have not used shared libraries, even going back to early 2.x versions.
Given cuuc is not a system library, at least on my release, wouldn't is be
better to default to trying even I you don't detect the library, other
tests do that, and it covers the cases where it's not a standard library
location, and it's been specified with -I / -L / -l options ?
A staticly linked postfix has the hash type on my build, so is linking
statically with Berkeley correctly. The cuuc wont link as the automatic
probe fails, and does not default to try compiling anyway (similar to the
way other tests do)
> Wietse
>
--
Yesterday is history and tomorrow is a mystery, the gift is now which is
why it is called the present..
