Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: More FreeBSD Problems! Graphics are not working.) - Solaris

This is a discussion on Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: More FreeBSD Problems! Graphics are not working.) - Solaris ; On Fri, 28 Mar 2008 20:28:38 -0700, mike3 wrote: > On Mar 28, 9:11 pm, mike3 wrote: Follow-up set to alt.solaris.x86 Be sure to note this since this discussion has become completely off-topic in a FreeBSD NG. >> > Either ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 37

Thread: Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: More FreeBSD Problems! Graphics are not working.)

  1. Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: More FreeBSD Problems! Graphics are not working.)

    On Fri, 28 Mar 2008 20:28:38 -0700, mike3 wrote:
    > On Mar 28, 9:11 pm, mike3 wrote:


    Follow-up set to alt.solaris.x86

    Be sure to note this since this discussion has become completely off-topic
    in a FreeBSD NG.

    >> > Either that or edit the configure script and put a sha-bang at the
    >> > top

    >>
    >> > #!/bin/bash

    >>
    >> Thanks for the answer. I'll see how this goes.

    >
    > Anyway, it STILL doesn't work, gosh darnnit!
    >
    > The error I get is this, a ways into the "make":
    >
    > ---
    > Running configure in multilib subdir amd64 pwd:
    > /home/sgc-programming/gcc-4.3.0/i386-pc-solaris2.10 mkdir amd64


    Note that the compile is *not* done within the source tree but within the
    object tree. Make a directory "obj" in the same directory where you
    unpacked the sources and use it for the build.

    Take a look at how the native gcc was created by running 'gcc -v' and try
    to use as much of the same original configuration as possible. You
    can start by copying mine below. Make certain that your $CC and $CFLAGS
    are correct:

    [duhring@maxwell ~/obj]$ echo $CC; echo $CFLAGS
    /usr/sfw/bin/gcc
    -O2 -pipe -m32 -march=k8 -mtune=k8

    On reconsideration, you might want to change "k8" to "athlon" or "i686".

    Now chdir into the obj directory and execute the configure script:

    [duhring@maxwell ~]$ cd obj
    [duhring@maxwell ~/obj]$ ../gcc-4.3.0/configure --prefix=/opt/gnu
    --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld
    --without-gnu-ld --enable-shared --enable-threads=posix --with-system-zlib
    --disable-nls --enable-mpfr --with-gmp=/opt/sfw --with-mpfr=/opt/sfw
    --enable-languages=c,c++,fortran

    ...After a few lines of output...

    configure: creating ./config.status
    config.status: creating Makefile
    [duhring@maxwell ~/obj]$

    At this point you are ready to run `gmake bootstrap`

    ....snip...

    > This is awful


    Look at the bright side; you're probably learning something ;~>

    You should also read the files in the gcc-4.3.0/INSTALL directory, one
    step at a time.

    If your gmp and mpfr libraries are in /usr/local you will definitely want
    to export LDFLAGS='-L/usr/local/lib -R/usr/local/lib'. Don't ignore this
    or gcc will not even be able to find its own libs.

    I tried to build the thing too and got the same "cannot compute suffix
    error". But I saw none of that -m64 or xarch=generic64 nonsense, so even
    if you do get your CFLAGS sorted out your compile is going to fail.

    The thing is not ready for prime time; not even Debian Lenny uses it yet.

    Try building one of the gcc-4.2 compilers or just download and install the
    Studio 12 suite. Studio 12 includes an IDE which you might find useful.
    If you do insist on building a gcc-4 my CFLAGS and configure arguments as
    shown above should work properly for you.


  2. Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: MoreFreeBSD Problems! Graphics are not working.)

    On Mar 28, 11:27 pm, Dave Uhring wrote:
    > On Fri, 28 Mar 2008 20:28:38 -0700, mike3 wrote:
    > > On Mar 28, 9:11 pm, mike3 wrote:

    >
    > Follow-up set to alt.solaris.x86
    >
    > Be sure to note this since this discussion has become completely off-topic
    > in a FreeBSD NG.
    >
    > >> > Either that or edit the configure script and put a sha-bang at the
    > >> > top

    >
    > >> > #!/bin/bash

    >
    > >> Thanks for the answer. I'll see how this goes.

    >
    > > Anyway, it STILL doesn't work, gosh darnnit!

    >
    > > The error I get is this, a ways into the "make":

    >
    > > ---
    > > Running configure in multilib subdir amd64 pwd:
    > > /home/sgc-programming/gcc-4.3.0/i386-pc-solaris2.10 mkdir amd64

    >
    > Note that the compile is *not* done within the source tree but within the
    > object tree. Make a directory "obj" in the same directory where you
    > unpacked the sources and use it for the build.
    >
    > Take a look at how the native gcc was created by running 'gcc -v' and try
    > to use as much of the same original configuration as possible. You
    > can start by copying mine below. Make certain that your $CC and $CFLAGS
    > are correct:
    >
    > [duhring@maxwell ~/obj]$ echo $CC; echo $CFLAGS
    > /usr/sfw/bin/gcc
    > -O2 -pipe -m32 -march=k8 -mtune=k8
    >
    > On reconsideration, you might want to change "k8" to "athlon" or "i686".
    >
    > Now chdir into the obj directory and execute the configure script:
    >
    > [duhring@maxwell ~]$ cd obj
    > [duhring@maxwell ~/obj]$ ../gcc-4.3.0/configure --prefix=/opt/gnu
    > --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld
    > --without-gnu-ld --enable-shared --enable-threads=posix --with-system-zlib
    > --disable-nls --enable-mpfr --with-gmp=/opt/sfw --with-mpfr=/opt/sfw
    > --enable-languages=c,c++,fortran
    >
    > ...After a few lines of output...
    >
    > configure: creating ./config.status
    > config.status: creating Makefile
    > [duhring@maxwell ~/obj]$
    >
    > At this point you are ready to run `gmake bootstrap`
    >
    > ...snip...
    >
    > > This is awful

    >
    > Look at the bright side; you're probably learning something ;~>
    >
    > You should also read the files in the gcc-4.3.0/INSTALL directory, one
    > step at a time.
    >
    > If your gmp and mpfr libraries are in /usr/local you will definitely want
    > to export LDFLAGS='-L/usr/local/lib -R/usr/local/lib'. Don't ignore this
    > or gcc will not even be able to find its own libs.
    >
    > I tried to build the thing too and got the same "cannot compute suffix
    > error". But I saw none of that -m64 or xarch=generic64 nonsense, so even
    > if you do get your CFLAGS sorted out your compile is going to fail.
    >
    > The thing is not ready for prime time; not even Debian Lenny uses it yet.
    >
    > Try building one of the gcc-4.2 compilers or just download and install the
    > Studio 12 suite. Studio 12 includes an IDE which you might find useful.
    > If you do insist on building a gcc-4 my CFLAGS and configure arguments as
    > shown above should work properly for you.


    Tried the GCC 4.3.0 in separate directory with the CFLAGS and CC set
    like
    you said as environment variables, and the error seems to have
    changed.
    It's now this. It appears to be a 32/64-bit clash, because it
    stubbornly wants
    to include -m64 in the compile line:

    ---

    mkdir amd64
    /home/sgc-programming/gcc-build-4.3.0/./gcc/xgcc -B/home/sgc-
    programming/gcc-build-4.3.0/./gcc/ -B/usr/local/i386-pc-solaris2.10/
    bin/ -B/usr/local/i386-pc-solaris2.10/lib/ -isystem /usr/local/i386-pc-
    solaris2.10/include -isystem /usr/local/i386-pc-solaris2.10/sys-
    include -O2 -O2 -g -O2 -pipe -m32 -march=k8 -mtune=k8 -DIN_GCC -W
    -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-
    style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -
    DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,-
    h,libgcc_s.so.1 -Wl,-z,text -Wl,-z,defs -Wl,-M,libgcc.map -o amd64/
    libgcc_s.so.1.tmp -g -fkeep-inline-functions -m64 -B./ _muldi3_s.o
    _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o
    _ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o
    _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o
    _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o
    _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o
    _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o
    _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o
    _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o
    _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o
    _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o
    _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o
    _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o
    _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o
    _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o
    _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o
    _udiv_w_sdiv_s.o _udivmoddi4_s.o unwind-dw2_s.o unwind-dw2-fde_s.o
    unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o -lc && rm -f
    amd64/libgcc_s.so && if [ -f amd64/libgcc_s.so.1 ]; then mv -f amd64/
    libgcc_s.so.1 amd64/libgcc_s.so.1.backup; else true; fi && mv amd64/
    libgcc_s.so.1.tmp amd64/libgcc_s.so.1 && ln -s libgcc_s.so.1 amd64/
    libgcc_s.so
    ld: fatal: file _muldi3_s.o: wrong ELF class: ELFCLASS32 <<<<<<<<<<<<<
    **** THIS IS THE ERROR ****
    ld: fatal: File processing errors. No output written to amd64/
    libgcc_s.so.1.tmp
    collect2: ld returned 1 exit status
    gmake[5]: *** [libgcc_s.so] Error 1
    gmake[5]: Leaving directory `/home/sgc-programming/gcc-build-4.3.0/
    i386-pc-solaris2.10/amd64/libgcc'
    gmake[4]: *** [multi-do] Error 1
    gmake[4]: Leaving directory `/home/sgc-programming/gcc-build-4.3.0/
    i386-pc-solaris2.10/libgcc'
    gmake[3]: *** [all-multi] Error 2
    gmake[3]: Leaving directory `/home/sgc-programming/gcc-build-4.3.0/
    i386-pc-solaris2.10/libgcc'
    gmake[2]: *** [all-stage1-target-libgcc] Error 2
    gmake[2]: Leaving directory `/home/sgc-programming/gcc-build-4.3.0'
    gmake[1]: *** [stage1-bubble] Error 2
    gmake[1]: Leaving directory `/home/sgc-programming/gcc-build-4.3.0'
    gmake: *** [bootstrap] Error 2

    ---

    I'll give the GCC 4.2.x series a try instead now.

  3. Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: MoreFreeBSD Problems! Graphics are not working.)

    On Mar 28, 11:27 pm, Dave Uhring wrote:
    > On Fri, 28 Mar 2008 20:28:38 -0700, mike3 wrote:
    > > On Mar 28, 9:11 pm, mike3 wrote:

    >
    > Follow-up set to alt.solaris.x86
    >
    > Be sure to note this since this discussion has become completely off-topic
    > in a FreeBSD NG.
    >
    > >> > Either that or edit the configure script and put a sha-bang at the
    > >> > top

    >
    > >> > #!/bin/bash

    >
    > >> Thanks for the answer. I'll see how this goes.

    >
    > > Anyway, it STILL doesn't work, gosh darnnit!

    >
    > > The error I get is this, a ways into the "make":

    >
    > > ---
    > > Running configure in multilib subdir amd64 pwd:
    > > /home/sgc-programming/gcc-4.3.0/i386-pc-solaris2.10 mkdir amd64

    >
    > Note that the compile is *not* done within the source tree but within the
    > object tree. Make a directory "obj" in the same directory where you
    > unpacked the sources and use it for the build.
    >
    > Take a look at how the native gcc was created by running 'gcc -v' and try
    > to use as much of the same original configuration as possible. You
    > can start by copying mine below. Make certain that your $CC and $CFLAGS
    > are correct:
    >
    > [duhring@maxwell ~/obj]$ echo $CC; echo $CFLAGS
    > /usr/sfw/bin/gcc
    > -O2 -pipe -m32 -march=k8 -mtune=k8
    >
    > On reconsideration, you might want to change "k8" to "athlon" or "i686".
    >
    > Now chdir into the obj directory and execute the configure script:
    >
    > [duhring@maxwell ~]$ cd obj
    > [duhring@maxwell ~/obj]$ ../gcc-4.3.0/configure --prefix=/opt/gnu
    > --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld
    > --without-gnu-ld --enable-shared --enable-threads=posix --with-system-zlib
    > --disable-nls --enable-mpfr --with-gmp=/opt/sfw --with-mpfr=/opt/sfw
    > --enable-languages=c,c++,fortran
    >
    > ...After a few lines of output...
    >
    > configure: creating ./config.status
    > config.status: creating Makefile
    > [duhring@maxwell ~/obj]$
    >
    > At this point you are ready to run `gmake bootstrap`
    >
    > ...snip...
    >
    > > This is awful

    >
    > Look at the bright side; you're probably learning something ;~>
    >
    > You should also read the files in the gcc-4.3.0/INSTALL directory, one
    > step at a time.
    >
    > If your gmp and mpfr libraries are in /usr/local you will definitely want
    > to export LDFLAGS='-L/usr/local/lib -R/usr/local/lib'. Don't ignore this
    > or gcc will not even be able to find its own libs.
    >
    > I tried to build the thing too and got the same "cannot compute suffix
    > error". But I saw none of that -m64 or xarch=generic64 nonsense, so even
    > if you do get your CFLAGS sorted out your compile is going to fail.
    >
    > The thing is not ready for prime time; not even Debian Lenny uses it yet.
    >
    > Try building one of the gcc-4.2 compilers or just download and install the
    > Studio 12 suite. Studio 12 includes an IDE which you might find useful.
    > If you do insist on building a gcc-4 my CFLAGS and configure arguments as
    > shown above should work properly for you.


    Trying gcc-4.2.3 also led to problems (again 32/64 clash), but seemed
    to get quite far:

    ---

    /bin/sh ./libtool --mode=link /home/sgc-programming/gcc-build-4.2.3/./
    gcc/xgcc -B/home/sgc-programming/gcc-build-4.2.3/./gcc/ -B/usr/local/
    i386-pc-solaris2.10/bin/ -B/usr/local/i386-pc-solaris2.10/lib/ -
    isystem /usr/local/i386-pc-solaris2.10/include -isystem /usr/local/
    i386-pc-solaris2.10/sys-include -m64 -fexceptions -Iinclude -I././
    targ-include -I.//libc/include -O2 -O2 -pipe -m32 -march=k8 -mtune=k8
    -m64 -o libgcjgc.la -version-info 1:2:0 -rpath /usr/local/lib/amd64
    allchblk.lo alloc.lo blacklst.lo checksums.lo dbg_mlc.lo dyn_load.lo
    finalize.lo gc_dlopen.lo gcj_mlc.lo headers.lo malloc.lo mallocx.lo
    mark.lo mark_rts.lo misc.lo new_hblk.lo obj_map.lo os_dep.lo
    pcr_interface.lo ptr_chck.lo real_malloc.lo reclaim.lo specific.lo
    stubborn.lo typd_mlc.lo backgraph.lo win32_threads.lo
    pthread_support.lo pthread_stop_world.lo darwin_stop_world.lo
    mach_dep.lo -L/usr/lib/lwp/amd64 -R/usr/lib/lwp/amd64 -
    lpthread -lthread -lrt
    /home/sgc-programming/gcc-build-4.2.3/./gcc/xgcc -B/home/sgc-
    programming/gcc-build-4.2.3/./gcc/ -B/usr/local/i386-pc-solaris2.10/
    bin/ -B/usr/local/i386-pc-solaris2.10/lib/ -isystem /usr/local/i386-pc-
    solaris2.10/include -isystem /usr/local/i386-pc-solaris2.10/sys-
    include -m64 -shared -Wl,-h -Wl,libgcjgc.so.1 -o .libs/libgcjgc.so.
    1.0.2 .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/
    checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/
    gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/
    mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/
    new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/
    ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/
    stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/
    win32_threads.o .libs/pthread_support.o .libs/
    pthread_stop_world.o .libs/darwin_stop_world.o .libs/mach_dep.o -R/
    usr/lib/lwp/amd64 -L/usr/lib/lwp/amd64 -lpthread -lthread -lrt -lc
    ld: fatal: file .libs/allchblk.o: wrong ELF class: ELFCLASS32
    ld: fatal: File processing errors. No output written to .libs/
    libgcjgc.so.1.0.2
    collect2: ld returned 1 exit status
    gmake[6]: *** [libgcjgc.la] Error 1
    gmake[6]: Leaving directory `/home/sgc-programming/gcc-build-4.2.3/
    i386-pc-solaris2.10/amd64/boehm-gc'
    gmake[5]: *** [all-recursive] Error 1
    gmake[5]: Leaving directory `/home/sgc-programming/gcc-build-4.2.3/
    i386-pc-solaris2.10/amd64/boehm-gc'
    gmake[4]: *** [multi-do] Error 1
    gmake[4]: Leaving directory `/home/sgc-programming/gcc-build-4.2.3/
    i386-pc-solaris2.10/boehm-gc'
    gmake[3]: *** [all-multi] Error 2
    gmake[3]: Leaving directory `/home/sgc-programming/gcc-build-4.2.3/
    i386-pc-solaris2.10/boehm-gc'
    gmake[2]: *** [all-recursive] Error 1
    gmake[2]: Leaving directory `/home/sgc-programming/gcc-build-4.2.3/
    i386-pc-solaris2.10/boehm-gc'
    gmake[1]: *** [all-target-boehm-gc] Error 2
    gmake[1]: Leaving directory `/home/sgc-programming/gcc-build-4.2.3'
    gmake: *** [bootstrap] Error 2

    ---


  4. Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: More FreeBSD Problems! Graphics are not working.)

    On Fri, 28 Mar 2008 23:44:14 -0700, mike3 wrote:

    > Tried the GCC 4.3.0 in separate directory with the CFLAGS and CC set
    > like
    > you said as environment variables, and the error seems to have
    > changed.
    > It's now this. It appears to be a 32/64-bit clash, because it
    > stubbornly wants
    > to include -m64 in the compile line:


    There may be something else in your environment causing that, perhaps
    CXXFLAGS. Try 'env | grep 64'.

    > I'll give the GCC 4.2.x series a try instead now.


    http://developers.sun.com/sunstudio/

    You probably have to register with Sun's Developer Network but that costs
    nothing.

    Or just download either of the Developer or Community versions of Nevada
    (Solaris 11 Pre):

    http://www.opensolaris.org/os/downloads/


  5. Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: More FreeBSD Problems! Graphics are not working.)

    On Sat, 29 Mar 2008 01:07:53 -0700, mike3 wrote:
    > On Mar 28, 11:27 pm, Dave Uhring wrote:


    >> [duhring@maxwell ~/obj]$ echo $CC; echo $CFLAGS
    >> /usr/sfw/bin/gcc
    >> -O2 -pipe -m32 -march=k8 -mtune=k8
    >>
    >> On reconsideration, you might want to change "k8" to "athlon" or "i686".


    It seems that changing the architecture is mandatory or you have something
    else in your environment which is causing the build to go to 64 bit mode.
    Try to see if there is:

    env | grep 64

    > Trying gcc-4.2.3 also led to problems (again 32/64 clash), but seemed
    > to get quite far:
    >
    > ---
    >
    > /bin/sh ./libtool --mode=link /home/sgc-programming/gcc-build-4.2.3/./
    > gcc/xgcc -B/home/sgc-programming/gcc-build-4.2.3/./gcc/ -B/usr/local/
    > i386-pc-solaris2.10/bin/ -B/usr/local/i386-pc-solaris2.10/lib/ -
    > isystem /usr/local/i386-pc-solaris2.10/include -isystem /usr/local/
    > i386-pc-solaris2.10/sys-include -m64 -fexceptions -Iinclude -I././
    > targ-include -I.//libc/include -O2 -O2 -pipe -m32 -march=k8 -mtune=k8
    > -m64


    Well, if nothing else works then vet the code by grepping through the
    source tree and replacing every instance of "-m64" with "-m32".

    ....snip rest of make output...

    Your other option is simply to install Studio 12.


  6. Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: MoreFreeBSD Problems! Graphics are not working.)

    On Mar 29, 2:17 am, Dave Uhring wrote:
    > On Fri, 28 Mar 2008 23:44:14 -0700, mike3 wrote:
    > > Tried the GCC 4.3.0 in separate directory with the CFLAGS and CC set
    > > like
    > > you said as environment variables, and the error seems to have
    > > changed.
    > > It's now this. It appears to be a 32/64-bit clash, because it
    > > stubbornly wants
    > > to include -m64 in the compile line:

    >
    > There may be something else in your environment causing that, perhaps
    > CXXFLAGS. Try 'env | grep 64'.
    >


    The "env | grep 64" shows this:
    LD_LIBRARY_PATH_64=/lib/amd64:/usr/lib/amd64:/usr/local/lib/:/usr/sfw/
    lib/amd64

    CXXFLAGS is not set, just as I usually do not set CC or CFLAGS (or
    LDFLAGS or any
    other compiler/linker parameters in general) in my environment. I pass
    them all
    via command line in my day-to-day use of the compiler.

    > > I'll give the GCC 4.2.x series a try instead now.

    >
    > http://developers.sun.com/sunstudio/
    >
    > You probably have to register with Sun's Developer Network but that costs
    > nothing.
    >


    Hmm. But I'd like to get the GCC working as I like GNU's compilers.

    > Or just download either of the Developer or Community versions of Nevada
    > (Solaris 11 Pre):
    >
    > http://www.opensolaris.org/os/downloads/


    But I want to use it longer than 6 months and the license does not
    allow that.
    So I can't. Sorry

  7. Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: More FreeBSD Problems! Graphics are not working.)

    On Sat, 29 Mar 2008 11:50:11 -0700, mike3 wrote:
    > On Mar 29, 2:17 am, Dave Uhring wrote:


    >> There may be something else in your environment causing that, perhaps
    >> CXXFLAGS. Try 'env | grep 64'.
    >>

    >
    > The "env | grep 64" shows this:
    > LD_LIBRARY_PATH_64=/lib/amd64:/usr/lib/amd64:/usr/local/lib/:/usr/sfw/
    > lib/amd64


    LD_LIBRARY_PATH should *never* be set in your environment. It is a total
    abomination which has no place whatever in an operating system using ELF.
    Google 'ld_library_path evil'.

    The compile time link editor /usr/ccs/bin/ld recognizes the -R/lib_path
    argument in your $LDFLAGS and properly places the run time library search
    paths into the executable binaries.

    In addition, /usr/local is another abomination. The use of /usr is
    strictly reserved for Sun. If you read the man page for filesystem you
    will find this:

    /opt

    Root of a subtree for add-on application packages.

    > Hmm. But I'd like to get the GCC working as I like GNU's compilers.


    Good luck. I just wasted a few hours trying to get gcc-4.2.3 built on a
    system using amd64-x2. FWIW, the farthest I got was with this:

    [duhring@maxwell ~/obj]$ echo $CC; echo $CFLAGS
    /usr/sfw/bin/gcc
    -O2 -pipe -m32
    [duhring@maxwell ~/obj]$ ../gcc-4.2.3/configure --prefix=/opt/gnu
    --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld
    --without-gnu-ld --enable-shared --enable-threads=posix
    --with-system-zlib --disable-nls --enable-mpfr
    --enable-languages=c,c++,fortran --with-gmp=/opt/sfw --with-mpfr=/opt/sfw

    >> Or just download either of the Developer or Community versions of
    >> Nevada (Solaris 11 Pre):
    >>
    >> http://www.opensolaris.org/os/downloads/

    >
    > But I want to use it longer than 6 months and the license does not allow
    > that.
    > So I can't. Sorry


    The Community editions are updated on a two-week schedule, the Developer
    Editions are updated quarterly. You would *want* to upgrade anyway.

    But the Sun Studio compiler suite is available without any 6 month
    restriction of which I'm aware. If you are running on UltraSPARC hardware
    then you most certainly want this compiler. Gcc sucks on SPARC.


  8. Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: More FreeBSD Problems! Graphics are not working.)

    On Sat, 29 Mar 2008 11:50:11 -0700 (PDT), mike3 wrote:
    >>
    >> http://developers.sun.com/sunstudio/
    >>
    >> You probably have to register with Sun's Developer Network but that costs
    >> nothing.
    >>

    >
    > Hmm. But I'd like to get the GCC working as I like GNU's compilers.


    I find GCC generally so-so. Wide availability, and quite good C++
    conformance. But there are a lot of things that let the side down as
    well - sloppy acceptance of errors, far too many nonstandard extensions
    which encourage nonportable code, byzantine command line options that
    are not orthogonal. For me a major thing is that GCC is about twice as
    slow at compiling as Sun Studio (debug mode) in the tests that I've
    done.

    A bientot
    Paul
    --
    Paul Floyd http://paulf.free.fr

  9. Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: MoreFreeBSD Problems! Graphics are not working.)

    On Mar 29, 1:23*pm, Dave Uhring wrote:
    > On Sat, 29 Mar 2008 11:50:11 -0700, mike3 wrote:
    > > On Mar 29, 2:17 am, Dave Uhring wrote:
    > >> There may be something else in your environment causing that, perhaps
    > >> CXXFLAGS. *Try 'env | grep 64'.

    >
    > > The "env | grep 64" shows this:
    > > LD_LIBRARY_PATH_64=/lib/amd64:/usr/lib/amd64:/usr/local/lib/:/usr/sfw/
    > > lib/amd64

    >
    > LD_LIBRARY_PATH should *never* be set in your environment. *It is a total
    > abomination which has no place whatever in an operating system using ELF.
    > Google 'ld_library_path evil'.
    >


    But some things seem to require it to be set to something. Otherwise I
    get
    library not found problems with some programs.

    Could this be causing the error I posted about:
    "ld: fatal: file _muldi3_s.o: wrong ELF class: ELFCLASS32"

    "_muldi3_s.o" does not seem to exist though in the directories in
    LD_LIBRARY_PATH/LD_LIBRARY_PATH_64, but appears to have been
    a file created during the GCC build itself, suggesting a BUG in GCC.

    > The compile time link editor /usr/ccs/bin/ld recognizes the -R/lib_path
    > argument in your $LDFLAGS and properly places the run time library search
    > paths into the executable binaries.
    >
    > In addition, /usr/local is another abomination. *The use of /usr is
    > strictly reserved for Sun. *If you read the man page for filesystem you
    > will find this:
    >
    > * * */opt
    >
    > * * * * *Root of a subtree for add-on application packages.
    >


    Hmm.

    What's the problem with using /usr/local, anyway? Most GNU
    packages install to /usr/local, so I use that. I figured that by _not_
    fussing around with the paths like that it would be easier and/or
    cause less problems.

    > > Hmm. But I'd like to get the GCC working as I like GNU's compilers.

    >
    > Good luck. *I just wasted a few hours trying to get gcc-4.2.3 built on a
    > system using amd64-x2. *FWIW, the farthest I got was with this:
    >
    > [duhring@maxwell ~/obj]$ echo $CC; echo $CFLAGS
    > /usr/sfw/bin/gcc
    > -O2 -pipe -m32
    > [duhring@maxwell ~/obj]$ ../gcc-4.2.3/configure --prefix=/opt/gnu
    > *--with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld
    > *--without-gnu-ld --enable-shared --enable-threads=posix
    > *--with-system-zlib --disable-nls --enable-mpfr
    > *--enable-languages=c,c++,fortran --with-gmp=/opt/sfw --with-mpfr=/opt/sfw
    >
    > >> Or just download either of the Developer or Community versions of
    > >> Nevada (Solaris 11 Pre):

    >
    > >>http://www.opensolaris.org/os/downloads/

    >
    > > But I want to use it longer than 6 months and the license does not allow
    > > that.
    > > So I can't. Sorry

    >
    > The Community editions are updated on a two-week schedule, the Developer
    > Editions are updated quarterly. *You would *want* to upgrade anyway.
    >


    Actually, I would not like making frequent upgrades like that and
    trying to "surf"
    the "wave" if you will. I'd be running through DVDs, doing constant
    downloads,
    constantly reformatting the hard disk, etc.

    Furthermore, they say "NOT FOR PRODUCTION USE", which suggests if I
    ever use it for any "production" purpose (something I just might do
    with my
    computer, it's MY computer after all), I'd go against the license. I
    just might
    use this box for "production" purposes.

    > But the Sun Studio compiler suite is available without any 6 month
    > restriction of which I'm aware. *If you are running on UltraSPARC hardware
    > then you most certainly want this compiler. *Gcc sucks on SPARC.


    Actually, I do have a SPARC machine, but it's not running Solaris,
    rather
    Debian GNU/Linux instead.

  10. Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: More FreeBSD Problems! Graphics are not working.)

    On Sat, 29 Mar 2008 13:00:52 -0700, mike3 wrote:
    > On Mar 29, 1:23*pm, Dave Uhring wrote:


    >> LD_LIBRARY_PATH should *never* be set in your environment. *It is a total
    >> abomination which has no place whatever in an operating system using ELF.
    >> Google 'ld_library_path evil'.
    >>

    >
    > But some things seem to require it to be set to something. Otherwise I
    > get
    > library not found problems with some programs.


    Then you are linking them incorrectly. If you install a binary for which
    you cannot obtain the source, build and link it correctly then the proper
    way to circumvent the problem is to write a wrapper script which then
    executes the binary with LD_LIBRARY_PATH. Do not set that thing in your
    user's environment.

    See the man pages for ld.so.1(1) and ld(1).

    > Could this be causing the error I posted about: "ld: fatal: file
    > _muldi3_s.o: wrong ELF class: ELFCLASS32"


    Now that one is 32 bit; it appears that your build is trying to go 64 bit
    and it created a 32 bit object.

    > "_muldi3_s.o" does not seem to exist though in the directories in
    > LD_LIBRARY_PATH/LD_LIBRARY_PATH_64, but appears to have been a file
    > created during the GCC build itself, suggesting a BUG in GCC.


    Surely you don't think that the GNU compiler would have a BUG!
    Where is the file?

    [duhring@maxwell ~/obj]$ find . -name _muldi3_s.o
    ../gcc/libgcc/amd64/_muldi3_s.o
    ../gcc/libgcc/_muldi3_s.o
    ../prev-gcc/libgcc/amd64/_muldi3_s.o
    ../prev-gcc/libgcc/_muldi3_s.o
    ../stage1-gcc/libgcc/amd64/_muldi3_s.o
    ../stage1-gcc/libgcc/_muldi3_s.o

    >> In addition, /usr/local is another abomination. *The use of /usr is
    >> strictly reserved for Sun. *If you read the man page for filesystem
    >> you will find this:
    >>
    >> * * */opt
    >>
    >> * * * * *Root of a subtree for add-on application packages.
    >>
    >>

    > Hmm.
    >
    > What's the problem with using /usr/local, anyway? Most GNU packages
    > install to /usr/local, so I use that. I figured that by _not_ fussing
    > around with the paths like that it would be easier and/or cause less
    > problems.


    The problem with /usr/local is that it is part of /usr and is reserved for
    Sun. It is not for your use. Please re-read filesystem(5); it clearly
    states that /opt is for your use.

    >> The Community editions are updated on a two-week schedule, the
    >> Developer Editions are updated quarterly. *You would *want* to upgrade
    >> anyway.
    >>
    >>

    > Actually, I would not like making frequent upgrades like that and trying
    > to "surf"
    > the "wave" if you will. I'd be running through DVDs, doing constant
    > downloads,
    > constantly reformatting the hard disk, etc.


    Filesystem 1K-blocks Used Available Use% Mounted on
    /dev/dsk/c0t0d0s0 9832601K 7342166K 2392109K 76% /
    swap 1395592K 988K 1394604K 1% /etc/svc/volatile
    /usr/lib/libc/libc_hwcap2.so.1
    9832601K 7342166K 2392109K 76% /lib/libc.so.1
    swap 1394664K 60K 1394604K 1% /tmp
    swap 1394640K 36K 1394604K 1% /var/run
    /dev/dsk/c0t0d0s3 9825313K 45879K 9681181K 1% /a
    /dev/dsk/c0t1d0s7 14761704K 3356970K 11257117K 23% /export/home
    newton:/srv 20176612K 10731296K 8420372K 57% /mnt

    The filesystem /dev/dsk/c0t0d0s3 is reserved for the next upgrade. Why
    would you set up a system where repartitioning would be required?

    Using live upgrade it is not even necessary to burn a DVD for an upgrade.
    The upgrade can be done from the ISO image. Yes, it does take a bit of
    time to download a 3.5 GB image - so what? That's what broadband ISP
    service is for.

    Additionally, those Developer and Community builds prepare one for the
    upcoming release of Solaris 11. You get to learn how to use the new
    features of the next release before you *need* to do that.

    > Furthermore, they say "NOT FOR PRODUCTION USE", which suggests if I ever
    > use it for any "production" purpose (something I just might do with my
    > computer, it's MY computer after all), I'd go against the license. I
    > just might
    > use this box for "production" purposes.


    That disclaimer is an advisory that Sun will not support the OS, not a
    limitation on your use of it. Re-read the license; I gave you the
    document number and it can be found easily with google.

    >> But the Sun Studio compiler suite is available without any 6 month
    >> restriction of which I'm aware. *If you are running on UltraSPARC
    >> hardware then you most certainly want this compiler. *Gcc sucks on
    >> SPARC.

    >
    > Actually, I do have a SPARC machine, but it's not running Solaris,
    > rather
    > Debian GNU/Linux instead.


    Studio 12 works on amd64, provides the features you want and you don't
    have to waste days trying to build it from source.


  11. Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: MoreFreeBSD Problems! Graphics are not working.)

    On Mar 29, 3:32*pm, Dave Uhring wrote:
    > On Sat, 29 Mar 2008 13:00:52 -0700, mike3 wrote:
    > > On Mar 29, 1:23*pm, Dave Uhring wrote:
    > >> LD_LIBRARY_PATH should *never* be set in your environment. *It is a total
    > >> abomination which has no place whatever in an operating system using ELF.
    > >> Google 'ld_library_path evil'.

    >
    > > But some things seem to require it to be set to something. Otherwise I
    > > get
    > > library not found problems with some programs.

    >
    > Then you are linking them incorrectly. *If you install a binary for which
    > you cannot obtain the source, build and link it correctly then the proper
    > way to circumvent the problem is to write a wrapper script which then
    > executes the binary with LD_LIBRARY_PATH. *Do not set that thing in your
    > user's environment.
    >


    Hmm.

    > See the man pages for ld.so.1(1) and ld(1).
    >
    > > Could this be causing the error I posted about: "ld: fatal: file
    > > _muldi3_s.o: wrong ELF class: ELFCLASS32"

    >
    > Now that one is 32 bit; it appears that your build is trying to go 64 bit
    > and it created a 32 bit object.
    >


    So what can I do? Should I just replace all "-m64" with "-m32"?

    > > "_muldi3_s.o" does not seem to exist though in the directories in
    > > LD_LIBRARY_PATH/LD_LIBRARY_PATH_64, but appears to have been a file
    > > created during the GCC build itself, suggesting a BUG in GCC.

    >
    > Surely you don't think that the GNU compiler would have a BUG!
    > Where is the file?
    >
    > [duhring@maxwell ~/obj]$ find . -name _muldi3_s.o
    > ./gcc/libgcc/amd64/_muldi3_s.o
    > ./gcc/libgcc/_muldi3_s.o
    > ./prev-gcc/libgcc/amd64/_muldi3_s.o
    > ./prev-gcc/libgcc/_muldi3_s.o
    > ./stage1-gcc/libgcc/amd64/_muldi3_s.o
    > ./stage1-gcc/libgcc/_muldi3_s.o
    >


    So does this mean that my theory was right: GCC has a BUG
    in it?

    > >> In addition, /usr/local is another abomination. *The use of /usr is
    > >> strictly reserved for Sun. *If you read the man page for filesystem
    > >> you will find this:

    >
    > >> * * */opt

    >
    > >> * * * * *Root of a subtree for add-on application packages.

    >
    > > Hmm.

    >
    > > What's the problem with using /usr/local, anyway? Most GNU packages
    > > install to /usr/local, so I use that. I figured that by _not_ fussing
    > > around with the paths like that it would be easier and/or cause less
    > > problems.

    >
    > The problem with /usr/local is that it is part of /usr and is reserved for
    > Sun. *It is not for your use. *Please re-read filesystem(5); it clearly
    > states that /opt is for your use.
    >


    So then I should just uninstall everything that's in /usr/local?

    > >> The Community editions are updated on a two-week schedule, the
    > >> Developer Editions are updated quarterly. *You would *want* to upgrade
    > >> anyway.

    >
    > > Actually, I would not like making frequent upgrades like that and trying
    > > to "surf"
    > > the "wave" if you will. I'd be running through DVDs, doing constant
    > > downloads,
    > > constantly reformatting the hard disk, etc.

    >
    > Filesystem * * * * * 1K-blocks * * *Used Available Use% Mounted on
    > /dev/dsk/c0t0d0s0 * * 9832601K *7342166K *2392109K *76% /
    > swap * * * * * * * * *1395592K * * *988K *1394604K * 1% /etc/svc/volatile
    > /usr/lib/libc/libc_hwcap2.so.1
    > * * * * * * * * * * * 9832601K *7342166K *2392109K *76% /lib/libc.so.1
    > swap * * * * * * * * *1394664K * * * 60K *1394604K * 1% /tmp
    > swap * * * * * * * * *1394640K * * * 36K *1394604K * 1% /var/run
    > /dev/dsk/c0t0d0s3 * * 9825313K * *45879K *9681181K * 1% /a
    > /dev/dsk/c0t1d0s7 * *14761704K *3356970K 11257117K *23% /export/home
    > newton:/srv * * * * *20176612K 10731296K *8420372K *57% /mnt
    >
    > The filesystem /dev/dsk/c0t0d0s3 is reserved for the next upgrade. *Why
    > would you set up a system where repartitioning would be required?
    >


    Why bother with an additional filesystem when you should just be able
    to upgrade the existing one?

    > Using live upgrade it is not even necessary to burn a DVD for an upgrade.
    > The upgrade can be done from the ISO image. *Yes, it does take a bit of
    > time to download a 3.5 GB image - so what? *That's what broadband ISP
    > service is for.
    >
    > Additionally, those Developer and Community builds prepare one for the
    > upcoming release of Solaris 11. *You get to learn how to use the new
    > features of the next release before you *need* to do that.
    >
    > > Furthermore, they say "NOT FOR PRODUCTION USE", which suggests if I ever
    > > use it for any "production" purpose (something I just might do with my
    > > computer, it's MY computer after all), I'd go against the license. I
    > > just might
    > > use this box for "production" purposes.

    >
    > That disclaimer is an advisory that Sun will not support the OS, not a
    > limitation on your use of it. *Re-read the license; I gave you the
    > document number and it can be found easily with google.
    >


    Ahh. OK. But I'm still not liking this frequent-upgrade thing.

    > >> But the Sun Studio compiler suite is available without any 6 month
    > >> restriction of which I'm aware. *If you are running on UltraSPARC
    > >> hardware then you most certainly want this compiler. *Gcc sucks on
    > >> SPARC.

    >
    > > Actually, I do have a SPARC machine, but it's not running Solaris,
    > > rather
    > > Debian GNU/Linux instead.

    >
    > Studio 12 works on amd64, provides the features you want and you don't
    > have to waste days trying to build it from source.



  12. Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: More FreeBSD Problems! Graphics are not working.)

    On Sat, 29 Mar 2008 16:12:36 -0700, mike3 wrote:
    > On Mar 29, 3:32*pm, Dave Uhring wrote:


    >> Now that one is 32 bit; it appears that your build is trying to go 64 bit
    >> and it created a 32 bit object.
    >>

    >
    > So what can I do? Should I just replace all "-m64" with "-m32"?


    That does not work either. I have no idea what is required to build the
    thing on amd64. Even if you set your -march=athlon the scripts detect the
    presence of amd64 and the build terminates with error.

    >> Surely you don't think that the GNU compiler would have a BUG! Where is
    >> the file?


    > So does this mean that my theory was right: GCC has a BUG in it?


    I don't think that the compiler was test built on Solaris amd64. I did
    get gcc-4.1.2 built but I have no recollection of what CFLAGS I used. All
    I have is the arguments to the configure script.

    >> The problem with /usr/local is that it is part of /usr and is reserved
    >> for Sun. *It is not for your use. *Please re-read filesystem(5); it
    >> clearly states that /opt is for your use.
    >>
    >>

    > So then I should just uninstall everything that's in /usr/local?


    No real harm is done by using that location; it is just esthetically
    dirty. Even if the software defaults to /usr/local you do know that it
    can be configured to install anywhere you want it with the --prefix=
    argument to configure.

    >> The filesystem /dev/dsk/c0t0d0s3 is reserved for the next upgrade.
    >> *Why would you set up a system where repartitioning would be required?


    > Why bother with an additional filesystem when you should just be able to
    > upgrade the existing one?


    The upgrade can be done while using the old system. The only down time
    required is that taken by a reboot. Disk space is cheap.

    [duhring@maxwell ~]$ iostat -nE
    c1t0d0 Soft Errors: 0 Hard Errors: 275 Transport Errors: 0
    Vendor: PIONEER Product: DVD-RW DVR-112D Revision: 1.15 Serial No:
    Size: 0.00GB <0 bytes>
    Media Error: 0 Device Not Ready: 275 No Device: 0 Recoverable: 0
    Illegal Request: 0 Predictive Failure Analysis: 0
    c0t0d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
    Vendor: IBM-ESXS Product: DTN036W3UWDY10FN Revision: S25J Serial No:
    Size: 36.40GB <36401479680 bytes>
    Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
    Illegal Request: 0 Predictive Failure Analysis: 0
    c0t1d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
    Vendor: IBM-ESXS Product: DTN036W3UWDY10FN Revision: S25J Serial No:
    Size: 36.40GB <36401479680 bytes>
    Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
    Illegal Request: 0 Predictive Failure Analysis: 0

    Those SCSI drives cost $15.00 each.

    >> That disclaimer is an advisory that Sun will not support the OS, not a
    >> limitation on your use of it. *Re-read the license; I gave you the
    >> document number and it can be found easily with google.
    >>
    >>

    > Ahh. OK. But I'm still not liking this frequent-upgrade thing.


    You have your choice. Get ahead of the curve by running the newest system
    available or stay with the old release and get surprised by the way the
    next one operates.

    Besides, GNOME-2.20 on the Nevada releases is much prettier than the old
    GNOME-2.6 (aka JDS-3) on Solaris 10 :-)

    >> Studio 12 works on amd64, provides the features you want and you don't
    >> have to waste days trying to build it from source.


    When you get tired of pulling your hair out, download and install Studio
    12, then update it. A few patches are required and available.


  13. Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: MoreFreeBSD Problems! Graphics are not working.)

    On Mar 29, 6:37*pm, Dave Uhring wrote:
    > On Sat, 29 Mar 2008 16:12:36 -0700, mike3 wrote:
    > > On Mar 29, 3:32*pm, Dave Uhring wrote:
    > >> Now that one is 32 bit; it appears that your build is trying to go 64 bit
    > >> and it created a 32 bit object.

    >
    > > So what can I do? Should I just replace all "-m64" with "-m32"?

    >
    > That does not work either. *I have no idea what is required to build the
    > thing on amd64. *Even if you set your -march=athlon the scripts detectthe
    > presence of amd64 and the build terminates with error.
    >


    Also, I'm not so sure setting -march=athlon would work on an
    INTEL Core 2 processor.

    > >> Surely you don't think that the GNU compiler would have a BUG! Where is
    > >> the file?

    > > So does this mean that my theory was right: GCC has a BUG in it?

    >
    > I don't think that the compiler was test built on Solaris amd64. *I did
    > get gcc-4.1.2 built but I have no recollection of what CFLAGS I used. *All
    > I have is the arguments to the configure script.
    >


    Ooh.

    > >> The problem with /usr/local is that it is part of /usr and is reserved
    > >> for Sun. *It is not for your use. *Please re-read filesystem(5); it
    > >> clearly states that /opt is for your use.

    >
    > > So then I should just uninstall everything that's in /usr/local?

    >
    > No real harm is done by using that location; it is just esthetically
    > dirty. *Even if the software defaults to /usr/local you do know that it
    > can be configured to install anywhere you want it with the --prefix=
    > argument to configure.
    >


    Ah.

    > >> The filesystem /dev/dsk/c0t0d0s3 is reserved for the next upgrade.
    > >> *Why would you set up a system where repartitioning would be required?

    > > Why bother with an additional filesystem when you should just be able to
    > > upgrade the existing one?

    >
    > The upgrade can be done while using the old system. *The only down time
    > required is that taken by a reboot. *Disk space is cheap.
    >
    > [duhring@maxwell ~]$ iostat -nE
    > c1t0d0 * * * * * Soft Errors: 0 Hard Errors: 275 Transport Errors: 0
    > Vendor: PIONEER *Product: DVD-RW *DVR-112D Revision: 1.15 Serial No: *
    > Size: 0.00GB <0 bytes>
    > Media Error: 0 Device Not Ready: 275 No Device: 0 Recoverable: 0
    > Illegal Request: 0 Predictive Failure Analysis: 0
    > c0t0d0 * * * * * Soft Errors: 0 Hard Errors: 0 Transport Errors:0
    > Vendor: IBM-ESXS Product: DTN036W3UWDY10FN Revision: S25J Serial No: *
    > Size: 36.40GB <36401479680 bytes>
    > Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
    > Illegal Request: 0 Predictive Failure Analysis: 0
    > c0t1d0 * * * * * Soft Errors: 0 Hard Errors: 0 Transport Errors:0
    > Vendor: IBM-ESXS Product: DTN036W3UWDY10FN Revision: S25J Serial No: *
    > Size: 36.40GB <36401479680 bytes>
    > Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
    > Illegal Request: 0 Predictive Failure Analysis: 0
    >
    > Those SCSI drives cost $15.00 each.
    >


    I don't want to have to buy more hard disks. Not to mention I don't
    have a SCSI controller in my system so that would just add to the
    cost.

    > >> That disclaimer is an advisory that Sun will not support the OS, not a
    > >> limitation on your use of it. *Re-read the license; I gave you the
    > >> document number and it can be found easily with google.

    >
    > > Ahh. OK. But I'm still not liking this frequent-upgrade thing.

    >
    > You have your choice. *Get ahead of the curve by running the newest system
    > available or stay with the old release and get surprised by the way the
    > next one operates.
    >


    I'd rather not have something that has 6 months expiration date
    on it and forces me to keep upgrading all the time.

    > Besides, GNOME-2.20 on the Nevada releases is much prettier than the old
    > GNOME-2.6 (aka JDS-3) on Solaris 10 :-)
    >
    > >> Studio 12 works on amd64, provides the features you want and you don't
    > >> have to waste days trying to build it from source.

    >
    > When you get tired of pulling your hair out, download and install Studio
    > 12, then update it. *A few patches are required and available.


    I might try it if I can't get the GCC to go at all.

  14. Re: Solaris vs Linux vs FreeBSD on SPARC Machine

    mike3 wrote:
    > On Mar 29, 6:37 pm, Dave Uhring wrote:
    >> On Sat, 29 Mar 2008 16:12:36 -0700, mike3 wrote:


    >>> Why bother with an additional filesystem when you should just be able to
    >>> upgrade the existing one?

    >> The upgrade can be done while using the old system. The only down time
    >> required is that taken by a reboot. Disk space is cheap.
    >>

    >
    > I don't want to have to buy more hard disks.


    Just create a spare slice for the upgrade. What would would you rather
    have, an upgrade you can revert, or one you cant? An upgrade you can
    run on a live system, or one you can't?

    >>> Ahh. OK. But I'm still not liking this frequent-upgrade thing.

    >> You have your choice. Get ahead of the curve by running the newest system
    >> available or stay with the old release and get surprised by the way the
    >> next one operates.

    >
    > I'd rather not have something that has 6 months expiration date
    > on it and forces me to keep upgrading all the time.
    >

    Where you get that nonsense from?

    >> When you get tired of pulling your hair out, download and install Studio
    >> 12, then update it. A few patches are required and available.

    >
    > I might try it if I can't get the GCC to go at all.


    You could have downloaded and installed it dozens of times by now.

    --
    Ian Collins.

  15. Re: Solaris vs Linux vs FreeBSD on SPARC Machine

    mike3 wrote:
    >> Vendor: IBM-ESXS Product: DTN036W3UWDY10FN Revision: S25J Serial No:
    >> Size: 36.40GB <36401479680 bytes>
    >> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
    >> Illegal Request: 0 Predictive Failure Analysis: 0
    >> c0t1d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
    >> Vendor: IBM-ESXS Product: DTN036W3UWDY10FN Revision: S25J Serial No:
    >> Size: 36.40GB <36401479680 bytes>
    >> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
    >> Illegal Request: 0 Predictive Failure Analysis: 0
    >>
    >> Those SCSI drives cost $15.00 each.
    >>

    >
    > I don't want to have to buy more hard disks. Not to mention I don't
    > have a SCSI controller in my system so that would just add to the
    > cost.
    >


    36.4 GB is a typical size for a SCSI disk, and an unusual size for an
    IDE one. A search on DTN036W3UWDY10FN confirms my suspicion that they
    are SCSI

    What machine is this?

    I'm not sure what generates "illegal request", but 36.4 SCSI disks are
    likely to be at the end of their useful life if they have been in
    continuous service since new.



  16. Re: Solaris vs Linux vs FreeBSD on SPARC Machine

    On Sun, 30 Mar 2008 09:07:17 +0100, caveman wrote:

    >>> Those SCSI drives cost $15.00 each.


    > 36.4 GB is a typical size for a SCSI disk, and an unusual size for an
    > IDE one. A search on DTN036W3UWDY10FN confirms my suspicion that they
    > are SCSI


    You didn't have to look that far to discover that they are SCSI drives.


  17. Re: Solaris vs Linux vs FreeBSD on SPARC Machine

    Dave Uhring wrote:
    > On Sun, 30 Mar 2008 09:07:17 +0100, caveman wrote:
    >
    >>>> Those SCSI drives cost $15.00 each.

    >
    >> 36.4 GB is a typical size for a SCSI disk, and an unusual size for an
    >> IDE one. A search on DTN036W3UWDY10FN confirms my suspicion that they
    >> are SCSI

    >
    > You didn't have to look that far to discover that they are SCSI drives.
    >


    OK, I looked back and can see the device name indicates SCSI too I think.

    Either way, he does have a SCSI controller and a 36 GB disk is most
    likely to be on its last legs now *assuming* it has been in regular
    service and not stored in a box for 5 years.

  18. Re: Solaris vs Linux vs FreeBSD on SPARC Machine

    On Mar 30, 2:05 am, Ian Collins wrote:
    > mike3 wrote:
    > > On Mar 29, 6:37 pm, Dave Uhring wrote:
    > >> On Sat, 29 Mar 2008 16:12:36 -0700, mike3 wrote:
    > >>> Why bother with an additional filesystem when you should just be able to
    > >>> upgrade the existing one?
    > >> The upgrade can be done while using the old system. The only down time
    > >> required is that taken by a reboot. Disk space is cheap.

    >
    > > I don't want to have to buy more hard disks.

    >
    > Just create a spare slice for the upgrade. What would would you rather
    > have, an upgrade you can revert, or one you cant? An upgrade you can
    > run on a live system, or one you can't?
    >


    Well, I suppose. But how can you live-upgrade the system?

    > >>> Ahh. OK. But I'm still not liking this frequent-upgrade thing.
    > >> You have your choice. Get ahead of the curve by running the newest system
    > >> available or stay with the old release and get surprised by the way the
    > >> next one operates.

    >
    > > I'd rather not have something that has 6 months expiration date
    > > on it and forces me to keep upgrading all the time.

    >
    > Where you get that nonsense from?
    >


    Nonsense? From SUN's very own documents:

    http://developers.sun.com/sxde/entitlement_108.pdf

    "License Term: Six (6) months (subject to termination under the SLA).
    Either party may terminate this
    Agreement upon ten (10) days written notice to the other party."

    After that there is no more license term. The license term has
    expired,
    which means one can no longer use the software legally. The language
    up
    there is clear and plain and leaves no room for interpretation.

    > >> When you get tired of pulling your hair out, download and install Studio
    > >> 12, then update it. A few patches are required and available.

    >
    > > I might try it if I can't get the GCC to go at all.

    >
    > You could have downloaded and installed it dozens of times by now.
    >


    Hmmph.

    I suppose, once I finally get fed up with GCC.



  19. Re: Solaris vs Linux vs FreeBSD on SPARC Machine

    mike3 wrote:
    > On Mar 30, 2:05 am, Ian Collins wrote:
    >> mike3 wrote:
    >>> On Mar 29, 6:37 pm, Dave Uhring wrote:
    >>>> On Sat, 29 Mar 2008 16:12:36 -0700, mike3 wrote:
    >>>>> Why bother with an additional filesystem when you should just be able to
    >>>>> upgrade the existing one?
    >>>> The upgrade can be done while using the old system. The only down time
    >>>> required is that taken by a reboot. Disk space is cheap.
    >>> I don't want to have to buy more hard disks.

    >> Just create a spare slice for the upgrade. What would would you rather
    >> have, an upgrade you can revert, or one you cant? An upgrade you can
    >> run on a live system, or one you can't?
    >>

    >
    > Well, I suppose. But how can you live-upgrade the system?
    >

    man lucreate.

    >>>>> Ahh. OK. But I'm still not liking this frequent-upgrade thing.
    >>>> You have your choice. Get ahead of the curve by running the newest system
    >>>> available or stay with the old release and get surprised by the way the
    >>>> next one operates.
    >>> I'd rather not have something that has 6 months expiration date
    >>> on it and forces me to keep upgrading all the time.

    >> Where you get that nonsense from?
    >>

    >
    > Nonsense? From SUN's very own documents:
    >
    > http://developers.sun.com/sxde/entitlement_108.pdf
    >

    Ah, I didn't realise you were referring to SXDE. Just use the Community
    Edition instead.

    --
    Ian Collins.

  20. Re: Solaris vs Linux vs FreeBSD on SPARC Machine (was: Re: Was: MoreFreeBSD Problems! Graphics are not working.)

    I've just noticed something. I just tried clearing my LD_LIBRARY_PATH
    and
    LD_LIBRARY_PATH_64 env. variables, and using CFLAGS=-m32 (and ONLY
    that in my CFLAGS), and now I'm not getting the ELFCLASS32 error, but
    I'm
    getting this instead:
    ---
    checking how to hardcode library paths into programs... immediate
    checking whether stripping libraries is possible... no
    checking dynamic linker characteristics... solaris2.10 ld.so
    checking command to parse /home/sgc-programming/gcc-build-4.2.3/./gcc/
    nm output... failed
    checking if libtool supports shared libraries... yes
    checking whether to build shared libraries... yes
    checking whether to build static libraries... yes
    creating libtool
    updating cache ./config.cache
    configure: loading cache ./config.cache
    checking for i386-pc-solaris2.10-gfortran... /home/sgc-programming/gcc-
    build-4.2.3/./gcc/gfortran -B/home/sgc-programming/gcc-build-4.2.3/./
    gcc/ -B/opt/gnu/i386-pc-solaris2.10/bin/ -B/opt/gnu/i386-pc-
    solaris2.10/lib/ -isystem /opt/gnu/i386-pc-solaris2.10/include -
    isystem /opt/gnu/i386-pc-solaris2.10/sys-include
    checking whether we are using the GNU Fortran compiler... no
    checking whether /home/sgc-programming/gcc-build-4.2.3/./gcc/gfortran -
    B/home/sgc-programming/gcc-build-4.2.3/./gcc/ -B/opt/gnu/i386-pc-
    solaris2.10/bin/ -B/opt/gnu/i386-pc-solaris2.10/lib/ -isystem /opt/gnu/
    i386-pc-solaris2.10/include -isystem /opt/gnu/i386-pc-solaris2.10/sys-
    include accepts -g... no
    checking whether the GNU Fortran compiler is working... no
    configure: error: GNU Fortran is not working; the most common reason
    for that is that you might have linked it to shared GMP and/or MPFR
    libraries, and not set LD_LIBRARY_PATH accordingly. If you suspect any
    other reason, please report a bug in http://gcc.gnu.org/bugzilla,
    attaching /home/sgc-programming/gcc-build-4.2.3/i386-pc-solaris2.10/
    libgfortran/config.log
    make[1]: *** [configure-target-libgfortran] Error 1
    make[1]: Leaving directory `/home/sgc-programming/gcc-build-4.2.3'
    make: *** [all] Error 2
    ----

    So apparently I _DO_ have to set LD_LIBRARY_PATH. Looking in
    /home/sgc-programming/gcc-build-4.2.3/i386-pc-solaris2.10/libgfortran/
    config.log:

    ---
    configure:4690: result: no
    configure:4728: checking whether the GNU Fortran compiler is working
    configure:4742: /home/sgc-programming/gcc-build-4.2.3/./gcc/gfortran -
    B/home/sgc-programming/gcc-build-4.2.3/./gcc/ -B/opt/gnu/i386-pc-
    solaris2.10/bin/ -B/opt/gnu/i386-pc-solaris2.10/lib/ -isystem /opt/gnu/
    i386-pc-solaris2.10/include -isystem /opt/gnu/i386-pc-solaris2.10/sys-
    include -c conftest.f >&5
    ld.so.1: f951: fatal: libmpfr.so.1: open failed: No such file or
    directory
    ---

    I'm going to try it now with LD_LIBRARY_PATH set but
    LD_LIBRARY_PATH_64
    NOT set. Maybe that might get it to work.

+ Reply to Thread
Page 1 of 2 1 2 LastLast