Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!kosciusko.esd.3com.com!mdb
From: mdb@kosciusko.esd.3com.com (Mark D. Baushke)
Newsgroups: gnu.gcc.bug
Subject: trouble in gcc 1.36 defining *_LIBCALL macros
Message-ID: <8910040745.AA16922@kosciusko.ESD.3Com.COM>
Date: 4 Oct 89 07:45:15 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: 3Com, 2081 N. Shoreline Blvd., Mountain View, CA 94043
Lines: 33

Environment: gcc 1.36 running under SunOS 3.5 configured to build 
executable for a non-Sun 68k machine.

Is there any good reason that the _LIBCALL macros are in effect being
run through ASM_OUTPUT_LABELREF(file,name) ?

In gcc 1.35, I could use

#define MODSI3_LIBCALL	"lmodt"

and the external symbol reference which was generated would literally
be "lmodt".

In gcc 1.36, this define will generate an external symbol reference of
"_lmodt". 

I would rather have the *_LIBCALL routine names NOT be run through the
same macro as the user-level labels.

Unless I am missing something, there currently appears to be no way to
generate references to the symbols I need to use...those which do NOT
have a leading "_" in their names.

Does anyone have a suggested workaround (other than re-naming the
library)?

BTW: I *do* want user-defined symbols to have the leading "_" in their
name. I just do not want a user-defined symbol to ever be able to
point to any of the special 'hardwired' library routine name.
--
Mark D. Baushke
Internet:   mdb@ESD.3Com.COM
UUCP:	    {3comvax,auspex,sun}!bridge2!mdb