Kolab install failure on gcc

Thu May 15 23:52:14 CEST 2008

On Thu, May 15, 2008 at 9:09 PM, Ryan Jacobson <rejacobson at gmail.com> wrote:
> Hello,
> Thanks for your reply.
>
> I have read the Kolab wiki for fedora/redhat installs, and actually had to
> apply the fix involving --hash-style=gnu being seen as an invalid option.  I
> got to the point where I'm at now after I applied that fix.
>
> There weren't any other fixes that I could find in the wiki that applied to
> the problem I'm having.

You are compiling on a 64bits host!
Problems with 64bits are still quite frequent.
Dont use a 64bits architecture just because you have a 64bits capable processor.

Reuse a SPEC file from another distribution will not give you more help.
Openpkg is a lot different of common distributions: staticaly linked
binaries, version number are stripped from directory of filename, ...

Maybe use last OS distribution like Fedora8 and last Kolab version
like 2.2rc2 will give you more chance of success.
At least 2.2 dont need the gcc trick.

Regards

>
> Ryan
>
>
>
> On Thu, May 15, 2008 at 11:52 AM, Alain Spineux <aspineux at gmail.com> wrote:
>>
>> On Thu, May 15, 2008 at 6:56 PM, Ryan Jacobson <rejacobson at gmail.com>
>> wrote:
>> > Hello,
>> >
>> > As per the subject line, I'm having trouble completing an install of
>> > Kolab
>> > 2.1.0
>> >
>>
>> Their is one workaround in the Kolab's wiki for fedora/redhat
>> distributions. Did you read it ?
>>
>> > I've had to tweak a few things to get it halfway installed, but it's now
>> > failing when attempting to build gcc.  I've found a potential fix that
>> > I'd
>> > like to try which involves modifying the gcc.spec file and adding
>> > --disable-multilib to the configure options
>> > (source:http://www.eforum.de/viewtopic.php?t=487).
>> >
>> > In order to try this I've unpacked the gcc.*.src.rpm package, modded the
>> > .spec file, and now I have to repack it into a src.rpm so I can re-add
>> > it to
>> > the Kolab install packages.  The problem I'm having is re-packing the
>> > src.rpm.  When I run "rpmbuild -bs gcc.spec" it doesn't recognize
>> > certain
>> > tags, such as CORE and %options, and refuses to create the src.rpm.
>> >
>> > Does anyone know how the Kolab rpms are packaged so I can duplicate it?
>> >  Or
>> > does anyone know if there's some way I can force rpmbuild to build the
>> > src.rpm anyway, despite it not recognizing those tags?  Or is there any
>> > other way around this problem? Perhaps I'm taking a very roundabout way
>> > of
>> > doing this.
>> >
>> > Here's some extra info about the install, with notes:
>> >
>> >
>> > ===========
>> > The Server
>> > ===========
>> > Fedora Core release 6 (Zod)
>> > Linux 2.6.20-1.2962.fc6 x86_64
>> >
>> >
>> >
>> > ======================================
>> > gcc-4.0.2: config.log (relevant lines)
>> > ======================================
>> > configure:1921: checking whether the C compiler (cc -fPIC ) works
>> > configure:1937: cc -o conftest -fPIC   conftest.c  1>&5
>> > /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgcc_s.so: file not recognized:
>> > File format not recognized
>> > collect2: ld returned 1 exit status
>> > configure: failed program was:
>> >
>> > #line 1932 "configure"
>> > #include "confdefs.h"
>> >
>> > main(){return(0);}
>> > --------------------------------------
>> > NOTES:
>> > This file
>> >  /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgcc_s.so
>> > links to
>> >  /lib64/libgcc_s.so.1
>> > which then links to
>> >  /lib64/libgcc_s-4.1.2-20070626.so.1
>> > --------------------------------------
>> >
>> >
>> >
>> > =======================================================
>> > gcc-4.0.2: configure script (relevant lines from above)
>> > =======================================================
>> > echo $ac_n "checking whether the C compiler ($CC $CFLAGS $LDFLAGS)
>> > works""... $ac_c" 1>&6
>> > echo "configure:1921: checking whether the C compiler ($CC $CFLAGS
>> > $LDFLAGS)
>> > works" >&5
>> >
>> > ac_ext=c
>> > # CFLAGS is not in ac_cpp because -g, -O, etc. are not valid cpp
>> > options.
>> > ac_cpp='$CPP $CPPFLAGS'
>> > ac_compile='${CC-cc} -c $CFLAGS $CPPFLAGS conftest.$ac_ext 1>&5'
>> > ac_link='${CC-cc} -o conftest${ac_exeext} $CFLAGS $CPPFLAGS $LDFLAGS
>> > conftest.$ac_ext $LIBS 1>&5'
>> > cross_compiling=$ac_cv_prog_cc_cross
>> >
>> > cat > conftest.$ac_ext << EOF
>> >
>> > #line 1932 "configure"
>> > #include "confdefs.h"
>> >
>> > main(){return(0);}
>> > EOF
>> > if { (eval echo configure:1937: \"$ac_link\") 1>&5; (eval $ac_link)
>> > 2>&5; }
>> > && test -s conftest${ac_exeext}; then
>> >   ac_cv_prog_cc_works=yes
>> >   # If we can't run a trivial program, we are probably using a cross
>> > compiler.
>> >   if (./conftest; exit) 2>/dev/null; then
>> >     ac_cv_prog_cc_cross=no
>> >   else
>> >     ac_cv_prog_cc_cross=yes
>> >   fi
>> > else
>> >   echo "configure: failed program was:" >&5
>> >   cat conftest.$ac_ext >&5
>> >   ac_cv_prog_cc_works=no
>> > fi
>> > rm -fr conftest*
>> > -------------------------------------------------------
>> > NOTES:
>> > It seems to be failing on one of the tests in the if block after it
>> > creates
>> > the "conftest" file.
>> > My shell scripting experience is limited but here's what I think the
>> > tests
>> > are doing:
>> >
>> > 1) The first test outputs logging info.
>> > 2) The second test compiles the just created conftest.c file into an
>> > executable.
>> > 3) The third test checks that the executable exists.
>> >
>> > (I've no idea what the 1>&5 or 2>&5 do)
>> >
>> > I've run those steps manually and it works fine so I don't see why it
>> > should
>> > be failing here.
>> > -------------------------------------------------------
>> >
>> >
>> >
>> >
>> >
>> > Any input/advice would be greatly appreciated and please let me know if
>> > more
>> > info from my end is needed.
>> >
>> > Thanks!
>> >
>> >
>> > Ryan Jacobson
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Kolab-users mailing list
>> > Kolab-users at kolab.org
>> > https://kolab.org/mailman/listinfo/kolab-users
>> >
>> >
>>
>>
>>
>> --
>> Alain Spineux
>> aspineux gmail com
>> May the sources be with you
>
>

-- 
Alain Spineux
aspineux gmail com
May the sources be with you