Subject: Notification: incoming/372

From: [email-masked]
Date: Wed, 2 Jun 1999 17:33:54 -0500 (CDT)

FVWM Bug Tracking notification

new message incoming/372

Message summary for PR#372
	From: [email-masked]
	Subject: configure bug?
	Date: Wed, 2 Jun 1999 17:33:53 -0500 (CDT)
	0 replies 	0 followups

====> ORIGINAL MESSAGE FOLLOWS <====

---

From: Steve Robbins <[email-masked]>
Date: Thu, 3 Jun 1999 00:24:48 -0400 (EDT)

On Wed, 2 Jun 1999 [email-masked] wrote:

> Full_Name: Jeff Solomon
> Version: 2.2
> CVS_Date: 
> OS: Solaris 2.5
> X_Server: NA
> Submission from: (NULL) (146.225.22.214)
> 
> 
> When detecting the Xpm library in the configure script, line 4389 is this:
> 
> LIBS="-l${smr_lib} ${xpm_LIBS} $X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS
> $LIBS"
> 
> This expands to something like this:
> 
> cc ... stuff ... -lXpm -L/my/Xpm/directory -lXpm
> 
> which doesn't work since the first -lXpm comes before the -L option that
> specifies
> where to find it.

Hmmm ... I never noticed that the library was repeated on the command line
like that! 

This was solaris 2.5?  What compiler?  Can you do it again with a fresh
copy of the sources, and email me the configure command line used, and the
config.log file?

So specifying the library before the search path ("... -lXpm -L/xpm/dir
...") gives a link error?  I'm a little surprised that this doesn't work. 
It will be tough to fix, since it involves changing an autoconf macro. 

Or maybe the problem was that "-lXpm" is repeated two times?  This would
be easier to fix, and wouldn't involve messing with autoconf proper.

> The fix for me was to remove the -l${smr_lib} from the
> LIBS line
> above. I also had to do a similar thing for readline. I believe removing it
> is OK
> since ${xpm_LIBS} should contain both the -l and the -L part (if necessary)

Sure, it is okay to do that. 

--
Steve Robbins                              <[email-masked]>

If mashed potatoes were security guards, they wouldn't get much done.

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 3 Jun 1999 09:31:21 -0400

> It will be tough to fix, since it involves changing an autoconf macro. 

Its not so much a problem as a link error as I don't want that one linked.
For example I have 
/usr/local/lib/libXpm... and /home/bgiaccio/lib/libXpm...

if I do gcc -lXpm -L/home/bgiaccio/lib -lXpm I get the first one the
compiler finds linked against, which happens to be in /usr/local and is
a very old version that I can't change.  So you deffinetlly don't want to 
repeat it unless you have to.

Brad

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Steve Robbins <[email-masked]>
Date: Fri, 4 Jun 1999 09:21:59 -0400 (EDT)

> repeat it unless you have to.

Ah, good point.  I'll have a look at this on the weekend.  

Since we ultimately use the autoconf macro AC_CHECK_LIB(Xpm,...), and
AC_CHECK_LIB itself inserts '-lXpm' before all the optional library flags
-- which is where the "-L/.... -lXpm" comes from, I see no option other
than rewriting the AC_CHECK_LIB autoconf macro.  Anyone got a better idea? 

A man came up to me and said, "I'd like to change your mind,
by hitting it with a rock," he said, "though I am not unkind."