[Coin-discuss] environment variables

[Matthew Saltzman]

On Mon, 10 Nov 2003, Stephan Hennig wrote:

> Hello,
>
> @Laszlo Ladanyi:
> Thanks alot for your answer. Osi/ now compiles fine with the OSL
> interface enabled. To be as much compliant to your "standards" I
> installed OSL within $(HOME)/osl. With the same argument I decided to
> try Red Hat because I found that distribution mentioned several times in
> the coin-discuss archive.
>
> Laszlo Ladanyi schrieb:
> > I'm not sure how much general *nix help you'll get here (to be honest this is
> > probably not the right forum for that), but I give a stab at a few of your
> > questions.
>
> I'll try to avoid asking basic unix questions here. But isn't RH one of
> the most buggy linuxes around? Sorry, no answer necessary.

Sorry, I'll answer anyway.  (I'm a Red Hat user, but I don't claim to
be a zealot.)  The answer is: No.  What makes you think that?

> Seems I'm constantly running into problems (am I repeating myself?).
> This time I tried to make the examples. Making Mkc stopped with some
> error complaining BCP_timeout.o could not be found. Making MaxCut rises
> the same error. You can find the console output from further make runs
> at the end of this mail. As you can see Bcp_timeout.o is touched just
> before the linker starts, but I can't find the Junk/ directory. When
> searching with Konqueror through the COIN/ directory structure for files
> that contain the string 'timeout' Konqueror (repeatingly) quits with an
> exception. That's good news when your just searching for another error,
> isn't it? I don't want to drive the OS to the limits and I'm *not*
> searching for bugs. Do you have any secret hint which Linux distribution
> I should try to avoid such messy things? RH already made problems during
> installation. The first time it reported hard disk errors that no other
> Windows low level program could find (I bought the HD 9 months ago). The
> next time RH installed fine without any repair having taken place. I
> don't have much confidence to RH.

It's hard to know what's going on with your install without knowing
exactly what you did, but of course, this is off-topic here.  Did you seek
support from the Red Hat mailing lists?  Did you get it?

I haven't made any significant use of Konqueror, but (1) you can't slam
Red Hat for this unless you know it works on other distributions; (2)
there are plenty of other tools for finding strings in subdirectories.
The classic Unix tool is "grep".

It's hard to recommend good basic Linux books, as the software moves
faster than the paper publishing industry can respond.  Having said that,
and after warning that I learned Unix/Linux the same way Laci did (sink or
swim), I will venture to recommend a few introductory books on Unix/Linux
that might be worth a look:

	From O'Reilly Press (www.ora.com), always the place I look first
	for practical computer books:

	Learning Red Hat Linux or Learning Debian GNU/Linux, by Bill
		McCarty
	Running Linux, by Matt Welsh
	Linux in a NuthShell
	Learning the Unix Operating System, by Jerry Peek et al.

	From Addison Wesley:

	Unix for the Impatient, by Paul W. Abrahams and Bruce R. Larson

Hope that helps.

>
> Sorry, back to BCP_timeout.XXX. Bcp/Makefile contains a part
>
> # Files containing member functions
> #BCP_SRC +=	BCP_vector_change.cpp
>
> BCP_SRC +=	BCP_lp_param.cpp
> BCP_SRC +=	BCP_USER.cpp
> BCP_SRC +=	BCP_timeout.cpp
>
> so I think BCP_timeout.cpp should be located in Bcp/Member . But there
> is no such file. There is no such file in COIN/ at all. I asked a friend
>  to checkout COIN/ on a Windows machine and he confirmed that he can't
> find that source file. What's wrong this time? Do you have any further
> hints for me?

As Laci pointed out, if your copy of the repository is up to date, there
should be no occurrence of BCP_timeout anywhere.

[mjs at yankee COIN]$ grep -r BCP_timeout *
[mjs at yankee COIN]$

(If you do have files containing references to BCP_timeout, they would be
listed between the prompts.)

If you still have trouble after "cvs update" and conflict resolution, I
would next try checking out a fresh copy of the repository in a different
directory and checking that.  It's possible CVS has become confused about
the state of your repository for some reason and won't bring it up to
date.

-- 
		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs