From: bin@primate.wisc.edu (Brain in Neutral)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Build X11R5 with Sun's Unbundled C Compiler
Date: 27 Aug 92 23:29:54 GMT
Distribution: fj
Organization: Workstation Div., Supermicro Systems Group, Sony Corporation

Date: 27 Aug 92 16:14:05 GMT
Message-Id: <6643@uakari.primate.wisc.edu>
Newsgroups: comp.windows.x

From article <9208231116.AA02677@simpson.turtles>, by amir@matis.UUCP (Amir Katz):
> Xperts,
> I've applied patches 13-16 and decided to build the release with Sun's
> Unbundled C Compiler (version SC1.0).
> The only problem is that the default linking rule for all X executables is
> something like:
> 
>    $(CC) -o $@ ${LDOPTIONS} ${OBJS} OBJECTS_DEFS LIBS_DEFS ...
> 
> LIBS_DEFS includes -L$(USRLIBDIR), which is defined to be /usr/lib.
> The macro USRLIBDIR, as I understand it, can't be changed since it also
> defines the place where libs are installed later. 

Yes, that wouldn't be a good idea.
 
> This causes all the linking rules to fail, since when one builds with Sun's
> Unbundled C Compiler, the path -L/usr/lang/SC1.0 MUST precede /usr/lib in
> order to pick up a special IEEE math lib (if not, you get an undefined
> symbol __start_libm or somesuch). 
 
> Using the Imake macros EXTRA_LIBRARIES or EXTRA_LOAD_FLAGS is no good, since
> they are placed in the LIBS_DEFS, which is too late.
 
> The logical candidate is LOCAL_LDFLAGS. Trouble is, I can't find any Imake
> variable that will be substituted for it.

There is none.  The intent of LOCAL_LDFLAGS, just as for make variables
INCLUDES, DEFINES and LOCAL_LIBRARIES, is that you can define them in
individual Imakefiles in order to effect a this-directory-only change.

> I hate to go into zillions of Imakefile's and manually add the definition of
> LOCAL_LDFLAGS.

That's what you need to do if you're going to use LOCAL_LDFLAGS the way
it's supposed to be used.  You could "cheat" and put

	LOCAL_LDFLAGS = -L/usr/lang/SC1.0

in your site.def or sun.cf.  That's a bad idea since you shouldn't directly
define any make variables in the site- or vendor-specific files, and it
prevents you from using LOCAL_LDFLAGS in an individual Imakefile for some
other purpose, and it will break your compile if you later switch to a
different compiler.  Still, it should help you get your distribution compiled
with the Sun compiler you're using now.

If you're intrepid and can change Imake.tmpl, you might instead try modifying
the definition of LDOPTIONS:

Change this:

#if AlternateUsrLibDir && defined(UseInstalled)
	LDOPTIONS = $(CDEBUGFLAGS) $(CCOPTIONS) $(LOCAL_LDFLAGS) -L$(USRLIBDIR)
#else
	LDOPTIONS = $(CDEBUGFLAGS) $(CCOPTIONS) $(LOCAL_LDFLAGS)

To this:
#if AlternateUsrLibDir && defined(UseInstalled)
	LDOPTIONS = $(CDEBUGFLAGS) $(CCOPTIONS) $(LOCAL_LDFLAGS) -L/usr/lang/SC1.0 -L$(USRLIBDIR)
#else
	LDOPTIONS = $(CDEBUGFLAGS) $(CCOPTIONS) $(LOCAL_LDFLAGS) -L/usr/lang/SC1.0

This isn't a great idea, either (you normally shouldn't mess with this
section of Imake.tmpl), but again, it might help you get your distribution
compiled.

I don't think it would work to modify LDLIBS because LDOPTIONS comes
before it in certain rules and LDOPTIONS contains -L$(USRLIBDIR) (see above),
which would defeat your purpose.

The real trouble is that the -L things in LDLIBS and LDOPTIONS aren't
specified in terms of variables that eventually get their definitions from
cpp macros which can be overridden in the site- or vendor-specific files.

Paul DuBois
dubois@primate.wisc.edu