Very Computer

this to some extent is true, but glib is the exception.  In order to use
networking (rpc) and Xwindow libraries you need the space wasting SCO
development systems libraries because most of them have references to
sco's /lib/libc.a and force you to use it rather than /usr/local/lib/libc.a ...
If anyone knows a way around this one, i'd give tons of money to them :)

-skito

--
                                                               here i am
                                                               here i am
                                                               waiting to hold

If you're on OpenServer 5, you should check out the Development System
that I posted info on yesterday.  It is compltely self-contained.  SCO
has provided headers, libraries, and the linker at no charge in the CD
and tape distributiosn of the OS in a manner that is usable with the GNU
stuff.

Assuming you're on 3.2v4-ish system, you're doomed.  This is why the
answer to this has long been, "the SCO development system is required."
A brave soul might buy just the TCP and/or NFS dev systems and try gluing
them to what you've got now, but if an upgrade to OpenServer 5 is
inevetable, this is one more reason to do it now.

If what is unresolved is smallish, you might be able to write your own
or "borrow" it from newlib or the BSD/Linux code if you're careful about
licensing.

Quote:>If anyone knows a way around this one, i'd give tons of money to them :)

My address is in the README from yesterday's post.  I'll be looking
for the money truck to pull up to my door. :-)

--

[ discussion that's been had a billion times on why you need SCO's
development system for pre-OpenServer releases to build non-trivial things
whacked ]

Quote:>>>development systems libraries because most of them have references to
>>>sco's /lib/libc.a and force you to use it rather than /usr/local/lib/libc.a ...

>>If you're on OpenServer 5, you should check out the Development System
>>that I posted info on yesterday.  It is compltely self-contained.  SCO
>>has provided headers, libraries, and the linker at no charge in the CD

[ whack ]

Quote:>>>If anyone knows a way around this one, i'd give tons of money to them :)

>>My address is in the README from yesterday's post.  I'll be looking
>>for the money truck to pull up to my door. :-)
>heh, not quite :)  gcc, gdb, and everything else gnu puts out works faster
>and for gcc creates smalelr executables than anything SCO or any commercial
>co. would try to put out.

That's simply not true.  Anytime you create a benchmark, you can create
a test case that you will win.  However, I have consistently found that
the Optimizing C Compiler (icc) that's now provided with the OpenServer 5
development system will create binaries that will simply pounce those
produced by GCC for raw computational speed.

I posted the dhrystones here once before from some of my tests.  The reality
is that GCC is an amazing compiler, but a compiler built to be portable
simply doesn't know as many "tricks of the chip" as a compiler built by
the people that build the chips.

The GNU tools certainly have a purpose in life.  Without a consistent
set of tools for the 20 or so UNIXen that I use, my life would be hell.
The ability to do cross development and embedded systems is way cool.
Stating that they will trounce all vendor tools across the board is
just wrong.

Quote:>co. would try to put out.  And I'm not convinced by your mail that OpenServer 5
>libraries do not have references to /lib/libc.a.

Oh.  They do.  But that's OK, becuase OpenServer 5 PROVIDES /lib/libc.a,
the headers, all the other libraries, and a linker.  See the READMEs from
my GNU distribution for OpenServer 5.  There's a custom-installable package
that gives you everything you need.

Quote:>In 3.2v4, -lintl -lrpc -lsocket and -lX11 have references to _ctype which is
>not an ansi standard implementation, thus forces you to link with /lib/libc.a
>This means you can't link with any other faster libraries like glib, because
>there would be major conflicts.

In OpenServer 5, if you have the Linkers and Libraries package installed,
you *have* libintl.a, librpc.a, libsocket.a, libX11.a, and all the other
stuff you need.

I've removed my own development system [ yikes ! ] and built mongo
quantities of net.stuff, including X apps on OpenServer 5 with only my
SCO/GNU ds.  Other users of this package report the same.

It works.  Really.

Quote:>the truck of money is loaded but it aint goin' nowhere.

Well, go get the keys.  You're going to need them.  I'll wait through
lunch if I need to.  :-)  

RJL
--

heh, not quite :)  gcc, gdb, and everything else gnu puts out works faster
and for gcc creates smalelr executables than anything SCO or any commercial
co. would try to put out.  And I'm not convinced by your mail that OpenServer 5
libraries do not have references to /lib/libc.a.

In 3.2v4, -lintl -lrpc -lsocket and -lX11 have references to _ctype which is
not an ansi standard implementation, thus forces you to link with /lib/libc.a
This means you can't link with any other faster libraries like glib, because
there would be major conflicts.

the truck of money is loaded but it aint goin' nowhere.

-skito

--
                                                               here i am
                                                               here i am
                                                               waiting to hold

obviously you haven't built gcc-2.7.0 with an i586 target.
i've had major success with warning flexibility and performance with
5 different programs that range from networking, cpu intensive,
and terminal interface beses.   The terminal and networking stuff is about
the same, but the two cpu intensive progs give a consistant 4% real-time
advantage, on a machine with no other users of course.

Quote:>I posted the dhrystones here once before from some of my tests.  The reality
>is that GCC is an amazing compiler, but a compiler built to be portable
>simply doesn't know as many "tricks of the chip" as a compiler built by
>the people that build the chips.

Yes, you can parse a little bit faster if you don't use a yacc generated
parser like gcc does to remain portable.  I do remember gcc-2.6.3's compile
times was a bit faster thatn the sco3.2v4 compiler, but alas gcc-2.7.0
compile time is (if i remember right) 3% slower thatn the sco compiler,
although the sco compiler doesn't generate 586 instructions and i doubt it
even generates 486 instructions since it must work for all pcs...

However, not necessarily with runtime output, if you have the optimizing/post
processing tools no trick can be unimplimentable unless the portible
programmer forgets it.  Just because something is portable doesn't mean
it will always lack system specific performance, this is the case with
compilers since you will always get the same instructional format that
you can optimize system dependelty after you lex and yacc.

Quote:>The GNU tools certainly have a purpose in life.  Without a consistent
>set of tools for the 20 or so UNIXen that I use, my life would be hell.
>The ability to do cross development and embedded systems is way cool.
>Stating that they will trounce all vendor tools across the board is
>just wrong.

agreed.

Quote:>>co. would try to put out.  And I'm not convinced by your mail that OpenServer 5
>>libraries do not have references to /lib/libc.a.

>Oh.  They do.  But that's OK, becuase OpenServer 5 PROVIDES /lib/libc.a,
>the headers, all the other libraries, and a linker.  See the READMEs from
>my GNU distribution for OpenServer 5.  There's a custom-installable package
>that gives you everything you need.

Oh.  They don't!  you just said they provide a /lib/libc.a which has it's
own headers which were probably used when they compiled the librpc.a and the
rest of the libraries, so they have references to the sytem dependednt
/lib/libc.a which means you must link with it and thus You cannot use
glib's /usr/local/lib/libc.a with sco librpc.a ...

Quote:>It works.  Really.

Not.

Quote:>>the truck of money is loaded but it aint goin' nowhere.

>Well, go get the keys.  You're going to need them.  I'll wait through
>lunch if I need to.  :-)  

Sorry.  next...

-skito

Just FYI - there are, for all practical purposes, no 486 or Pentium
specific instructions which are of any use to a C compiler.

All of the 486 and Pentium optimisations involve understanding the
instruction timing and sequencing charactersitics of each processor.
A piece of code which is highly optimised for the Pentium may be
sub-optimal for a 386, but it will run.

The optimising compiler generates a compromise between 486 and
Pentium optimised code by default - it can also optimise for a
specific target processor. (But in all cases the code will run
on any 386, 486 or Pentium).

finally someone who knows their stuff... after several communications
an obvious "possible" answer is reavealed to make glib work with sco's
other libraries.  It is to Simply extract the needed references from sco's
/lib/libc.a as a single binary .o and add append this to /usr/local/lib/libc.a
this of course is a "possible" solution because the extracted references
may directly conflict with the rest of /usr/local/lib/libc.a but it's
defintley worth a try.

here's the keys to the truck... you deserved it.

-skito (i still beleive the 586 cmpexch8 can made usefull to a compiler :)

--
                                                               here i am
                                                               here i am
                                                               waiting to hold