Subject: FVWM: Compiling on Solaris 8 x86

From: Dan D Niles <[email-masked]>
Date: Thu, 21 Jun 2001 16:23:05 -0500 (CDT)

I am trying to compile fvwm 2.2.5 on Solaris 8 x86.  When I run
configure it goes for a while and the produces the following error:

checking whether setvbuf arguments are reversed... configure: error: can not run test program while cross compiling

Any ideas?

Thanks,

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

---

From: Dan Espen <[email-masked]>
Date: Thu, 21 Jun 2001 18:41:25 -0400

> run test program while cross compiling

At the point where it decided it was using a cross compiler is
where it went wrong.

Look for the first failure.

I assume you are using gcc.  Is gcc working?

If you can't find the problem post the command you entered and
all the output.

If you are making changes, be sure to remove the configure.cache
between attempts.

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 24 Jun 2001 00:56:34 +0000

> checking whether setvbuf arguments are reversed... configure: error: can not run test program while cross compiling

This is often happens if you have broken c++ instalation. Try:

  ./configure --without-cxx

Or better yet, install fvwm-2.3.33, which does not use C++ and has much
less problems overall than fvwm-2.2.5.

Regards,
Mikhael.

---

From: Dan D Niles <[email-masked]>
Date: Mon, 25 Jun 2001 11:48:16 -0500 (CDT)

>   ./configure --without-cxx

This seems to have fixed it.  I am using the gcc package from
www.sunfreeware.com.  I guess that package is broken.

Thanks,

Dan

---

From: "Paul D. Smith" <[email-masked]>
Date: 25 Jun 2001 13:14:15 -0400

%% Dan D Niles <[email-masked]> writes:

  ddn> This seems to have fixed it.  I am using the gcc package from
  ddn> www.sunfreeware.com.  I guess that package is broken.

Not necessarily.

On Solaris, using the -L option to specify where to find shared
libraries is not enough.  That will help the compile-time linker ld(1)
find them, but it won't set the path for the run-time linker ld.so(1) to
find them.

On Solaris, when dealing with shared libraries that appear in
non-standard places, you also must use the -R option to set the run-time
link path.

If your installation of GCC uses a shared stdc++ (standard C runtime)
then you likely will need to add a -R flag to your compile line telling
the linker where to look.

For example, if your compiler installs its shared libraries in
/opt/gcc-2.95.2/lib, then you would do this:

  $ cd fvwm-2.2.5
  $ make clean
  $ rm config.cache
  $ LDFLAGS="-R/opt/gcc-2.95.2/lib" ./configure ...
  $ make

and that should work.

Whether it's this installation of GCC that is broken or whether it is
this behavior of Solaris that is broken, is an exercise for the reader.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>    HASMAT--HA Software Methods & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan D Niles <[email-masked]>
Date: Mon, 25 Jun 2001 12:52:02 -0500 (CDT)

>   ddn> www.sunfreeware.com.  I guess that package is broken.
[clip]
 >   $ LDFLAGS="-R/opt/gcc-2.95.2/lib" ./configure ...

That does not work.  It still thinks my C++ compiler is a cross-compiler,
and breaks during the configure.

Dan

---

From: "Paul D. Smith" <[email-masked]>
Date: 25 Jun 2001 14:23:47 -0400

ddn> That does not work.  It still thinks my C++ compiler is a
  ddn> cross-compiler, and breaks during the configure.

You're sure you used the right directory, right?  My example was just
that: an example.  I don't have the first idea where these files reside
on your system.  Look in the directory you provided via -R; you should
see a file libstdc++.so.<some-stuff> there.  If not, you don't have the
right directory.

In order to debug this further we'd need to see what configure prints
into config.log when it decides that the C++ compiler is a
cross-compiler.

---

From: Dan D Niles <[email-masked]>
Date: Mon, 25 Jun 2001 13:37:14 -0500 (CDT)

> see a file libstdc++.so.<some-stuff> there.  If not, you don't have the

Odd, I used:

LDFLAGS="-R/usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.2" ./configure

Which has libstdc++.so (a link) but not libstdc++.so.2.10.0.  The
libstdc++.so.2.10.0 file is in /usr/local/lib, but libstdc++.so is
not.  The following did work:

LDFLAGS="-R/usr/local/lib" ./configure

Perhaps this could be auto-configured when compiling on x86.  Is
this still necessary with the beta version of fvwm?

Dan

---

From: "Paul D. Smith" <[email-masked]>
Date: 25 Jun 2001 15:25:22 -0400

ddn> LDFLAGS="-R/usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.2" ./configure

  ddn> Which has libstdc++.so (a link) but not libstdc++.so.2.10.0.  The
  ddn> libstdc++.so.2.10.0 file is in /usr/local/lib, but libstdc++.so is
  ddn> not.

That is indeed a strange configuration.

  ddn> The following did work:

  ddn> LDFLAGS="-R/usr/local/lib" ./configure

  ddn> Perhaps this could be auto-configured when compiling on x86.

I don't see how configure could really know what the right path would
be.

Anyway, this isn't an x86 issue, it's a Solaris issue.  Solaris on SPARC
behaves the same way.

And, finally, if this issue can be resolved it really this issue needs
to be resolved by autoconf itself.  Possibly if/when we switch to the
next official autoconf (2.50) in FVWM, this won't be an issue (I don't
know; I haven't tried it--I _do_ know they fixed the cross-compiler
stuff so you won't see the confusing message you did here, but instead
something like "Can't find a working C++ compiler" or similar... because
I, among others, abused the autoconf folks until they changed it :).

  ddn> Is this still necessary with the beta version of fvwm?

Maybe.  The next release of FVWM doesn't need a C++ compiler at all, so
this particular manifestation doesn't exist.

However, you could run into the same issue with other shared libraries:
say you installed libXpm.so or the stroke or readline or whatever
libraries in directories other than the standard system directories;
then you need to add -R to get the run-time linker to look there as
well.