You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Nick Kew <ni...@apache.org> on 2009/11/21 23:24:57 UTC
Building on opensolaris
Just a heads-up in case anyone is interested: I've played with
building trafficserver on opensolaris/AMD64. Since I need to
be in a fit state tomorrow I'm knocking off now rather than
running a potentially-all-night session, so here's progress
to date:
1. Make a copy of trunk
2. Run autoconf and configure - FAIL
3. Browse to TS-11. Try the latest patch: it's in a format
neither I nor patch recognise. Try Theo's patch: mostly
works; go through the failures by hand.
4. Run autoconf and configure - fails with Sun CC testing
for and failing to find something in libssl. But gcc
is happy, so I take that as path of least resistance.
Also required a brief diversion to install libdb4.
5. Build: the first problem was __WORDSIZE undetined
(it had detected my arch as i586)! Added it to CFLAGS.
6. libinktomi++: several places where it complained of
conversions to different size, so I had to add casts.
7. madvise() is undefined. The declarations of madvise
in sys/mman.h are encased in #ifs, and I guess what it
needs is the right CFLAGS. Workaround by reverting
to the no-madvise code.
8. STL trouble: it's complaining of templates being
redefined (within a single .h files). Clearly a
case of needing the right CFLAGS to deal with the
templates, but that's where I've stopped for tonight.
I don't know when I'll return to this, but I expect I'll
finish the job and post some patches in the not-too-distant.
Re: Building on opensolaris
Posted by Nick Kew <ni...@apache.org>.
Theo Schlossnagle wrote:
> In the patch I submitted, the Solaris variant (for non gcc) sets:
>
> common_opt="-mt -m32 -D__WORDSIZE=32"
> debug_opt="-g $common_opt"
> release_opt="-g $common_opt -xO3"
> cxx_opt="-library=stlport4 -erroff"
>
> in configure.ac. So you shouldn't be hitting those issues.
Neither those options nor the gcc options work with any compiler
I've tried.
However, I now have a successful compilation with a slightly
different (and hacked) set of flags to /opt/SUNWspro/bin/cc.
For example, I had to remove the "-march=i586", not so much
because it's wrong as because Sun's compiler chokes on -march,
as well as on -mt and -m32 in your options.
Notable issue: I had to hack around
"ink_queue.h", line 113: Error: #error "unsupported processor".
I'm guessing __i386__ is the safe option here, but since I'm using
a 64-bit box it would perhaps be good if it could deal with it.
make install dies at:
/usr/bin/ginstall -c -m 644 './access\#denied'
'/usr/local/trafficserver/etc/trafficserver/body_factory/default/access\#denied'
/usr/bin/ginstall: cannot stat `./access\\#denied': No such file or
directory
Not sure whether that's an incompatible ginstall version
or a different-shell issue, but removing the backslash in
Makefile leads to
make: Fatal error: Don't know how to make target `access'
The good news is that gmake install works, so that's evidently
a gnu-ism! Perhaps just documenting "use gmake" would make sense.
So I now have an install. Next step is to repeat and get an
end-to-end build, then see if I can clean it to the point
of an alternative patch and/or list of issues.
--
Nick Kew
Re: Building on opensolaris
Posted by Theo Schlossnagle <je...@omniti.com>.
In the patch I submitted, the Solaris variant (for non gcc) sets:
common_opt="-mt -m32 -D__WORDSIZE=32"
debug_opt="-g $common_opt"
release_opt="-g $common_opt -xO3"
cxx_opt="-library=stlport4 -erroff"
in configure.ac. So you shouldn't be hitting those issues.
On Nov 21, 2009, at 5:39 PM, Nick Kew wrote:
>
> On 21 Nov 2009, at 22:24, Nick Kew wrote:
>
>> 8. STL trouble: it's complaining of templates being
>> redefined (within a single .h files). Clearly a
>> case of needing the right CFLAGS to deal with the
>> templates, but that's where I've stopped for tonight.
>
> Bah. It's not STL, it's just the first time a bunch of templates
> gets included, and that came ultimately from #include <string>!
> I'll follow up on that when I've figured it out.
>
> --
> Nick Kew
--
Theo Schlossnagle
http://omniti.com/is/theo-schlossnagle
p: +1.443.325.1357 x201 f: +1.410.872.4911
Re: Building on opensolaris
Posted by Nick Kew <ni...@apache.org>.
On 21 Nov 2009, at 22:24, Nick Kew wrote:
> 8. STL trouble: it's complaining of templates being
> redefined (within a single .h files). Clearly a
> case of needing the right CFLAGS to deal with the
> templates, but that's where I've stopped for tonight.
Bah. It's not STL, it's just the first time a bunch of templates
gets included, and that came ultimately from #include <string>!
I'll follow up on that when I've figured it out.
--
Nick Kew
Re: Building on opensolaris
Posted by Bryan Call <bc...@yahoo-inc.com>.
On 11/21/2009 02:24 PM, Nick Kew wrote:
> Just a heads-up in case anyone is interested: I've played with
> building trafficserver on opensolaris/AMD64. Since I need to
> be in a fit state tomorrow I'm knocking off now rather than
> running a potentially-all-night session, so here's progress
> to date:
>
> 1. Make a copy of trunk
> 2. Run autoconf and configure - FAIL
> 3. Browse to TS-11. Try the latest patch: it's in a format
> neither I nor patch recognise. Try Theo's patch: mostly
> works; go through the failures by hand.
The patch was created using git (git format-patch trunk). There is some
extra email and stats at the front of the patch. My patch program
ignores these and applies the patch without issues.
I added a new patch that is just the diff:
https://issues.apache.org/jira/secure/attachment/12425892/0002-bcall-solaris_updates.patch
> 4. Run autoconf and configure - fails with Sun CC testing
> for and failing to find something in libssl. But gcc
> is happy, so I take that as path of least resistance.
> Also required a brief diversion to install libdb4.
> 5. Build: the first problem was __WORDSIZE undetined
> (it had detected my arch as i586)! Added it to CFLAGS.
> 6. libinktomi++: several places where it complained of
> conversions to different size, so I had to add casts.
> 7. madvise() is undefined. The declarations of madvise
> in sys/mman.h are encased in #ifs, and I guess what it
> needs is the right CFLAGS. Workaround by reverting
> to the no-madvise code.
> 8. STL trouble: it's complaining of templates being
> redefined (within a single .h files). Clearly a
> case of needing the right CFLAGS to deal with the
> templates, but that's where I've stopped for tonight.
>
> I don't know when I'll return to this, but I expect I'll
> finish the job and post some patches in the not-too-distant.