OK -- building mon fails...

Making all in XrdMon
/bin/sh ../../libtool --tag=CXX   --mode=link g++  -g -O2 -D_REENTRANT -static  -o xrdmonAdmin XrdMonSndAdminApp.o -lresolv 
libtool: link: g++ -g -O2 -D_REENTRANT -o xrdmonAdmin XrdMonSndAdminApp.o  ./.libs/libXrdMonDummySender.a ./.libs/libXrdMonCommon.a -lresolv
Undefined symbols:
  "_Swap_n2hll", referenced from:
      XrdMonSndCoder::prepare2Transfer(std::vector<XrdMonSndTraceEntry, std::allocator<XrdMonSndTraceEntry> > const&)in libXrdMonDummySender.a(XrdMonSndCoder.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [xrdmonAdmin] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

and building doc fails after I disable mon to stop it from blocking:

/bin/sh: no: command not found
make[1]: *** [doc] Error 127
make: *** [all-recursive] Error 1

After those are gone, things seem to run smoothly.



On Sep 22, 2010, at 8:01 AM, Lukasz Janyst wrote:

> Hi Alden,
>   the autotools build should be fixed now in git head. You can
> download a snapshot from here (for some reason the repository visible
> via http is not synced with the one on the afs...):
>   I have tested it to work on: Debian Squeeze, SLC5, MacOS X 10.6.4
> and SunOS 5.10 sparc. Could you check if it works for you?
> Cheers,
>   Lukasz
> On Sat, Sep 18, 2010 at 1:25 PM, Lukasz Janyst <[log in to unmask]> wrote:
>> Yes, indeed. The autotools build is broken on 64 bits Macs because,
>> contrary to the assumption of the autoconf script, the compiling
>> toolchain supports three architectures there and not just two. You can
>> workaround this problem by disabling the perl interface if you don't
>> need it (--disable-perlint parameter of the configure script) or by
>> using the classical build. There are also two other problems with the
>> autotools stuff. The first one is the missing libtoolize binary called
>> from the script (on Mac it's called glibtoolize). Also,
>> the autotools build tries to link the xrootd binary to a dynamically
>> loadable module which results with a linking error. On Mac there is a
>> clear distinction between loadable modules and shared libraries which
>> is not the case for the ELF systems where both are the same and this
>> is why this problems has been introduced and not spotted earlier.
>> Anyways, thanks for reporting. I will be fixing that on Monday.
>> Cheers,
>>   Lukasz
>> On Sat, Sep 18, 2010 at 7:22 AM, Alden Stradling
>> <[log in to unmask]> wrote:
>>> as the config file requested --
>>> ./
>>> ./ -i /opt/xrootd
>>> ./
>>> ./configure -h
>>> ./configure --prefix=/opt/xrootd --enable-pwd --enable-posix --enable-mon --enable-apps --enable-doc --enable--gsi
>>> configure: WARNING: perl says it was linked with multiple -arch flags (-arch i386 -arch ppc)! Will try to remove one
>>> configure: WARNING: perl says it was compiled with multiple -arch flags (-arch i386 -arch ppc)! Will try to remove one
>>> configure: error: Failed to remove extra -arch flags
>>>                     LD: -arch x86_64 -arch i386
>>>                     CC: -arch x86_64 -arch i386  -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -I/usr/local/include -I/System/Library/Perl/5.10.0/darwin-thread-multi-2level/CORE
>>> !!!!!!  Please notify maintainers at [log in to unmask] !!!!!!
>>> OS X 10.6.4, Mac Pro x86_64