Re: DG/UX Port - Giving Up!!

[Robert Lipe <robertlipe@usa.net>]

I've never seen DG/UX, but some of these sound familiar to me.

Eric Raskin wrote:

> I'm giving up on the DG/UX Intel port of egcs (i586-dg-dguxR4.20MU03).
> In order to make everything work, you need to switch from the DG/UX
> assembler and linker to the GNU versions.  If you don't, then the
> "weak" designations don't work properly, and the stage2-to-stage3
> compare operation during the bootstrap fails.  If you do change, then
> you break the compiler supplied with the base OS (which specifies
> some funky switches to the DG assembler in order to fix up debugging
> information).

It is entirely possible to have the GNU assembler and the native
assembler on the same system if that's what you're asking.  If the issue
is that you need to GCC to call the two assemblers with different flags,
there is prior art for that, too.  (Look in configure.in and search for
"sco5gas".  If configured --with-gnu-as that target will forget about
all the funky flags to pass to the assembler and instead use a set that
will work with GAS.  Note how sco5gas.h just sets a flag and "wraps" the
current sco5.h.)

> I've also found that debugging with the new tools is completely
> broken -- I can't get dbx or gdb to debug anything produced by the
> GNU assember/linker tools.  As a matter of fact, I can't even get the
> objcopy utility to copy an ELF executable properly when produced by
> any of the three compilers on my system -- gcc 2.7.2 (base OS), gcc
> 2.8.1 (built myself) and egcs 19990502 snapshot.  The debugging info
> gets trashed.  (I'm using binutils 2.9.1.)

You may be able to tinker with the debugging formats used.  If you have
an all-GNU toolchain (and compatibility with the native chain isn't
important), stabs are probably the thing to use.  The way I read dgux.h, 
it prefers to use DWARF1 but does also build in stabs.   Try turning that
on (using -gstabs) and see if it makes life better for you.  If you like
it, then just configure your tree with --with-stabs to make it the default.

In general, I found that trying to debug everything (gcc, ld, as, gdb)
at once was really hard.  I'd focus on getting the compiler to work well
enough to do a bootstrap with native binary tools then iterate over the 
debugger and GNU binutils to bring those up.

Of course, there are those on the list that scoff at such things since
they're so studly as to be able to effectively debug all those things in
parallel while using an system with bad RAMs. :-)


> Finally, I've found that the egcs C++ implementation on DG/UX won't
> call global constructors/destructors from shared libraries.  It
> isn't just dynamic linking using dlopen(), it's even the DG/UX
> version of ld.so that won't do it.  On DG/UX, this file is called
> /usr/dglib/libc.so.1, for anyone who cares to take a look at it.

We had (and fixed!) this very problem in OpenServer just before 1.1.2
went out.  Look in the Feb egcs-bugs archives for the threads:

	Final patch for shared library problem in SCO OpenServer
	shared library patch for SCO OpenServer 5.0.5 & egcs

If yours is an ELF-based SVR4-ish systems (and I think it is) you might
find this to be pertinent.

It may be as simple as ensuring that crti.o abd crtn.o get linked in
the right places if your system provides these.

> So, I'm giving up on this port.  It's now beyond my abilities.

It doesn't sound like you're that far from the finish line, really.


RJL