C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details.
XNOR
The Solaris environment is killing me...
I wanted to install Midnight Commander but I saw that it needs to be
compiled.
To compile Midnight Commander I downloaded gtk but I couldn`t install
gtk. Because it needed many other dependency packages.
I downloaded other dependency packages and I couldn`t have installed
even them.
I am really very angry at the moment.
Then I found something/script `pkg-get` from www.blaswave.org and run
it. Pkg-get installed many
things by downloading them somewhere from internet.
Actually I don`t know where am I now? Because when I run ./configure
to install/compile Midnight Commander, the following message appear:
bash-3.00#
bash-3.00# /Desktop/mc-4.6.1/configure
checking for a BSD-compatible install... /Desktop/mc-4.6.1/config/
install-sh -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... no
checking whether to enable maintainer-specific portions of
Makefiles... no
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
checking for style of include used by make... none
checking for gcc... no
checking for cc... cc
checking for C compiler default output file name... configure: error:
C compiler cannot create executables
See `config.log' for more details.
bash-3.00#
----------------------------------------------------------------------------------------------
Could you please advise me how can I install by fixing that problem?
Regards
Oscar del Rio
> I wanted to install Midnight Commander but I saw that it needs to be
> compiled.
nope!
http://www.blastwave.org
http://www.sunfreeware.com
they both have it, take your pick
Oscar del Rio
Look for "mc" in either blastwave or sunfreeware...
Gary Mills
>XNOR wrote:
>> I wanted to install Midnight Commander but I saw that it needs to be
>> compiled.
>http://www.blastwave.org
>http://www.sunfreeware.com
>they both have it, take your pick
Or, if you are using one of the graphical desktops, CDE or JDS3,
why not use the built-in graphical file manager.
--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
XNOR
Thank you very much.I got it from www.blastwave.com and installed but
I have one more question about the matter.
I 've installed it but when I type mc in command line, it doesn't
start. How can I start the MidnightCommander?
regards
Rich Teer
> checking for gcc... no
> checking for cc... cc
> checking for C compiler default output file name... configure: error:
> C compiler cannot create executables
> See `config.log' for more details.
> bash-3.00#
>
> ----------------------------------------------------------------------------------------------
> Could you please advise me how can I install by fixing that problem?
Others have answered this specific problem, but I think this article
I wrote might be useful reading for you:
http://developers.sun.com/solaris/articles/build_sw_on_solaris.html
NB the bit about setting $PATH...
--
Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member
CEO,
My Online Home Inventory
Voice: +1 (250) 979-1638
URLs: http://www.rite-group.com/rich
http://www.myonlinehomeinventory.com
Oscar del Rio
> Thank you very much.I got it from www.blastwave.com and installed but
> I have one more question about the matter.
> I 've installed it but when I type mc in command line, it doesn't
> start. How can I start the MidnightCommander?
Type the entire path
/opt/csw/bin/mc
or add /opt/csw/bin to your PATH environment (details depend on what shell you
are using, sh/bash/ksh/tcsh etc)
XNOR
I type;
#/opt/csw/bin/mc
The following message is shown:
#ld.so.1:mc:fatal:libintl.so.3:open failed: No such file or directory
Killed
#
#
actualy there is a file, /opt/csw/bin/mc
Regards
ThanksButNo
Sounds like you also need to set LD_LIBRARY_PATH to point to the
shared libraries.
One piece at a time, you'll get it!
:-)
Rich Teer
> Sounds like you also need to set LD_LIBRARY_PATH to point to the
> shared libraries.
Here we go again: any piece of software that requires the use of
LD_LIBRARY_PATH is most likely broken, i.e., built incorrectly.
The use of -R flags at build time will eliminate this "requirement".
gerryt
> I type;
> #/opt/csw/bin/mc
> The following message is shown:
> #ld.so.1:mc:fatal:libintl.so.3:open failed: No such file or directory
> Killed
> actualy there is a file, /opt/csw/bin/mc
Where did this mc come from? pkg-get should install dependencies for
package "mc".
If ld cannot locate it then the install is borked or the package is.
On the SPARC platform
the mc package installs fine. I suspect the x86 package installs fine
as well.
mc is not a GUI - its more like a curses app. So I think you wont like
it even if you finally
get it working : /
XNOR
Hello Gary,
I am studying Solaris, actually I don't need to neither mc nor
anything else. Problems and working on problems are teaching me
Solaris and helping me know and getting experience Solaris
environment.
Regards
XNOR
> > I have one more question about the matter.
> > I 've installed it but when I type mc in command line, it doesn't
> > start. How can I start the MidnightCommander?
>
> Type the entire path
>
> /opt/csw/bin/mc
>
> or add /opt/csw/bin to your PATH environment (details depend on what shell you
> are using, sh/bash/ksh/tcsh etc)
Hello,
I am using
sh (#)
and
bash-3.00#
Should I enter following command?
#set path=(. /opt/csw/bin/)
Regards
XNOR
Hi,
This is a challenge to myself. I am going to get result by anyway. :)
I did a scan,
About 20 different files contain LD_LIBRARY_PATH parameter in
computer. Which one will I edit?
Thanks&Regards
XNOR
Hello,
I got it from www.blastwave.com and can locate mc.
I am constant to get working it and I am not going to give up until it
works.
Thanks&Regards
Meliksah
gerryt
> On 24 Mart, 20:15, "gerryt" <lepsys...@gmail.com> wrote:
>
>
>
> > On Mar 23, 2:57 pm, "XNOR" <meliksah.kara...@gmail.com> wrote:
>
> > > I type;
> > > #/opt/csw/bin/mc
> > > The following message is shown:
> > > #ld.so.1:mc:fatal:libintl.so.3:open failed: No such file or directory
> > > Killed
> > > actualy there is a file, /opt/csw/bin/mc
>
> > Where did this mc come from? pkg-get should install dependencies for
> > package "mc".
> > If ld cannot locate it then the install is borked or the package is.
> > On the SPARC platform
> > the mc package installs fine. I suspect the x86 package installs fine
> > as well.
>
> > mc is not a GUI - its more like a curses app. So I think you wont like
> > it even if you finally get it working : /
But mc cannot load at least one pre-requisite library. This is wrong
and broken. I dont even know how you can accomplish that feat.
> I am constant to get working it and I am not going to give up until it works.
Well thats good but It should be working already. A simple:
# pkg-get -i mc
is all thats needed assuming you installed pkg-get correctly,
have some thing of sane exportable PATH, and (optionally)
edited /opt/csw/etc/pkg-get.conf to suit.
A simple example PATH for bash and blastwave usage:
# wipe inherited PATH clean
PATH=""
# Just in case export PATH. No harm done
export PATH=/usr/sfw/bin:/bin:/sbin:/usr/openwin/bin:/usr/sbin:/usr/
ccs/bin:/usr/dt/bin:/opt/csw/bin
Save to /.xnor
As root:
# exec bash
type:
. /.xnor
Now what happens when you try to run "mc"??
ThanksButNo
I generally set it in /etc/profile, unless you're using csh.
ThanksButNo
> On Fri, 23 Mar 2007, ThanksButNo wrote:
> > Sounds like you also need to set LD_LIBRARY_PATH to point to the
> > shared libraries.
>
> Here we go again: any piece of software that requires the use of
> LD_LIBRARY_PATH is most likely broken, i.e., built incorrectly.
> The use of -R flags at build time will eliminate this "requirement".
>
Well I beg to differ. You don't always have the option of being in
charge of building the software. There is the occasion of purchasing
something from somebody coz it's cheaper than trying to make your own.
Now, if the executable is looking for a specific shared library, and
it's not situated among the usual locations, what are you supposed to
do? Call up the vendor and tell them to rebuild their product with a
better "-R" flag? Or set LD_LIBRARY_PATH such that it find the shared
libraries, where they may happen to reside?
It's either that or copy/move/link the libraries to where the
executable can find it. Personally, I'd rather set the envar.
Indeed, adjusting LD_LIBRARY_PATH is often in the installation
instructions. Thus, the vendor doesn't need to assume that you're
going to put his product into a directory hierarchy that matches his
own -- you can put things where you want, and set up the environment
variables to match.
Jeez, I never thought something this simple would create controversy!
Rich Teer
> Well I beg to differ. You don't always have the option of being in
> charge of building the software. There is the occasion of purchasing
> something from somebody coz it's cheaper than trying to make your own.
True. And if you pay for something, presumably you have someone
to complain to.
> Now, if the executable is looking for a specific shared library, and
> it's not situated among the usual locations, what are you supposed to
> do? Call up the vendor and tell them to rebuild their product with a
Yes.
> better "-R" flag? Or set LD_LIBRARY_PATH such that it find the shared
> libraries, where they may happen to reside?
Lomg term, get the vendor to fix their software. Short term,
write a wrapper script that sets LD_LIBRARY_PATH just for
running the errant program. Setting LD_LIBRARY_PATH in .profile
or the like is about the worst thing you can do.
> Indeed, adjusting LD_LIBRARY_PATH is often in the installation
Yeah, probably 'cause the developers of said software have it
set in their environment all the time, and don't think of the
consequences. Please see the "Linking With Libraries" section
of this document I wrote for more:
http://developers.sun.com/solaris/articles/build_sw_on_solaris.html
> Jeez, I never thought something this simple would create controversy!
Bad advice is bad advice... :-) Mind you, this isn't as bad as
advocating remote root logins!
Rich Teer
> I generally set it in /etc/profile, unless you're using csh.
That's about the worst possible place you could put it! Bascially,
you're fscking up the environment of all your users. Putting it in
your .profile is almost as bad, but at least then only your user's
environment gets FUBARed.
ThanksButNo
> On Sat, 24 Mar 2007, ThanksButNo wrote:
> > I generally set it in /etc/profile, unless you're using csh.
>
> That's about the worst possible place you could put it! Bascially,
> you're fscking up the environment of all your users. Putting it in
> your .profile is almost as bad, but at least then only your user's
> environment gets FUBARed.
>
> --
> Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member
>
Sorry -- I'm not used to running heterogeneous development
environments.
I'm used to running a homogeneous customer environment, where each and
every user on the machine is there for exactly one purpose -- to run
the one or more applications provided for them by our company.
Indeed, under such circumstance, /etc/profile is the perfect place to
put controls for where to find things. When something changes, you
only have the one file that needs to be updated.
No, our users don't change their home .profile. We don't let them.
They don't have different values for LD_LIBRARY_PATH. There's no
need.
As a matter of fact, our developers don't change their own .profile
either. None of them care to learn more Unix than is necessary to get
their job done. So I set them all up with a global environment.
Within the global /etc/profile, no one needs to worry about where
Oracle is located, or Sybase, or TeleUSE, or gcc, or any of a dozen
other utilities we use. And if I need to move Sybase to a new
location, or upgrade everyone to a new version while keeping the old
one for historical or comparison purposes, again, I only need to
update the environment in a single location.
And if I do it right, no one is the wiser. Everybody's scripts,
everybody's programs, everything works just the way it did before,
even with half the planet moved.
Yah, if I do it wrong, then I "fsck it up" for everybody. But it
doesn't take long to discover the mistake and rectify it. Somebody
will try to run something and it will fail, and I'll get an
interesting batch of e-mails and phone calls.
As I said before -- I never thought something so simple could generate
so much controversy. Sheesh.
Paul Floyd
> Should I enter following command?
> #set path=(. /opt/csw/bin/)
No. Don't put . in your path. And append/prepend /opt/csw/bin:
set path=($path /opt/csw/bin)
A bientot
Paul
Paul Floyd
>
> Well I beg to differ. You don't always have the option of being in
> charge of building the software. There is the occasion of purchasing
> something from somebody coz it's cheaper than trying to make your own.
>
> Now, if the executable is looking for a specific shared library, and
> it's not situated among the usual locations, what are you supposed to
> do? Call up the vendor and tell them to rebuild their product with a
> better "-R" flag? Or set LD_LIBRARY_PATH such that it find the shared
> libraries, where they may happen to reside?
>
> It's either that or copy/move/link the libraries to where the
> executable can find it. Personally, I'd rather set the envar.
No. Don't do it. If the app is badly built, then use a shell script or
shell function. Don't pollute your global shell environment with
LD_LIBRARY_PATH.
> Indeed, adjusting LD_LIBRARY_PATH is often in the installation
> instructions. Thus, the vendor doesn't need to assume that you're
> going to put his product into a directory hierarchy that matches his
> own -- you can put things where you want, and set up the environment
> variables to match.
Perhaps these clueless vendors should read the manual, in particular wrt
%ORIGIN.
> Jeez, I never thought something this simple would create controversy!
Giving people bad advice in an ng like this is always likely to stir up
somewhat heated replies.
A bientot
Paul
Paul Floyd
> either. None of them care to learn more Unix than is necessary to get
> their job done.
With that sort of attitude, I bet your software is shit.
A bientot
Paul
Ian Collins
> On Mar 24, 8:07 pm, Rich Teer <rich.t...@rite-group.com> wrote:
>
>>On Sat, 24 Mar 2007, ThanksButNo wrote:
>>
>>>I generally set it in /etc/profile, unless you're using csh.
>>
>>That's about the worst possible place you could put it! Bascially,
>>you're fscking up the environment of all your users. Putting it in
>>your .profile is almost as bad, but at least then only your user's
>>environment gets FUBARed.
>>
>
> so much controversy. Sheesh.
>
cause a well built application to fail by loading an incorrect library.
Real example - a client had LD_LIBRARY_PATH=/usr/local/lib in their
environment which caused Blastwave Subversion to crap out due to an
older version of a dependant library in /usr/local.
--
Ian Collins.
Rich Teer
> > Should I enter following command?
> > #set path=(. /opt/csw/bin/)
>
> No. Don't put . in your path. [...]
Especially at the beginning of it!
--
Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member
CEO,
ThanksButNo
> On 25 Mar 2007 00:53:22 -0700, ThanksButNo <no.no.tha...@gmail.com> wrote:
>
> > either. None of them care to learn more Unix than is necessary to get
> > their job done.
>
> With that sort of attitude, I bet your software is shit.
>
> A bientot
> Paul
Oh thanks a lot, I can't start my day without my morning coffee and
newsgroup flame.
And I suppose your software is wonderfully put together with all the
unique and wondrous attributes available from the underlying OS, and
you follow the advice in all of Rich Teer's books to the letter.
Just too bad it just doesn't get the job done.
No offense intended. Just trying to make a point here, without
resorting to insults.
We're over-worked, under-capitalized, under-paid, and under-
appreciated. We have jobs to do, customers to keep happy, and
families to spend quality time with. When we sell a product, the
customer couldn't care less how much Unix we know. All they care
about is that the product balances their books, manages their trades,
schedules their deliveries, handles their formula pricing, invoices
their customers, notifies them of changes, etc. etc. etc.
Rich Teer, bless his heart, sells Unix expertise. We don't.
Now I'm sure you think we don't know what we're doing anyway. That's
fine, you don't pay a nickel of our salaries.
Sheesh!
ThanksButNo
Yah, you have a point, and I understand it.
But it doesn't change *my* point.
*IF* we run into such a situation, and I can think of a couple of
examples myself, *THEN* we'll make a wrapper script.
My point is, some things can and *should* be global, and everyone on
the system can and *should* use the same environment. In those
instances, /etc/profile is as good a place as any to put it. In other
instances, you might need to create something more personalized. So
then you need a wrapper script.
You don't need to automatically always make a wrapper script, just
because there's a *possibility* of finding a library conflict. Most
of the time, it's just a matter of adding that application's own set
of libraries that came with it to the end of the path. The rest of
the time, *IF* you run into a problem, *THEN* you fix it.
Frank Cusack
> *IF* we run into such a situation, and I can think of a couple of
> examples myself, *THEN* we'll make a wrapper script.
That's a great attitude. Let's wait until something crashes and
burns, instead of pre-emptively applying well established best
practice techniques to head off any problems in the first place.
-frank
Frank Cusack
> the system can and *should* use the same environment.
Absolutely. LD_LIBRARY_PATH isn't one of them.
-frank
Ian Collins
> On Mar 25, 1:19 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>
>>ThanksButNo wrote:
>>
>>>As I said before -- I never thought something so simple could generate
>>>so much controversy. Sheesh.
>>
>>Because it's bad advice! Setting LD_LIBRARY_PATH in the environment can
>>cause a well built application to fail by loading an incorrect library.
>> Real example - a client had LD_LIBRARY_PATH=/usr/local/lib in their
>>environment which caused Blastwave Subversion to crap out due to an
>>older version of a dependant library in /usr/local.
>>
>
> Yah, you have a point, and I understand it.
>
> But it doesn't change *my* point.
>
> the system can and *should* use the same environment.
I agree, but LD_LIBRARY_PATH isn't one of them. Well OK, it is, it
should be unset globally.
--
Ian Collins.
ThanksButNo
> On 25 Mar 2007 16:13:03 -0700 "ThanksButNo" <no.no.tha...@gmail.com> wrote:
>
> > *IF* we run into such a situation, and I can think of a couple of
> > examples myself, *THEN* we'll make a wrapper script.
>
> That's a great attitude. Let's wait until something crashes and
> burns, instead of pre-emptively applying well established best
> practice techniques to head off any problems in the first place.
>
> -frank
Yah, that's my attitude --
It's a long-established practice called "Don't Fix What Ain't Broke"
Frank Cusack
I think a more accurate summary would be "Don't plan ahead."
Rich Teer
> My point is, some things can and *should* be global, and everyone on
> the system can and *should* use the same environment. In those
I couldn't agree more; it's just that LD_LIBRARY_PATH isn't one of
those things.
--
Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member
CEO,
Rich Teer
> It's a long-established practice called "Don't Fix What Ain't Broke"
But ironically, what we're talking about (the practice of universally
setting LD_LIBRARY_PATH) *IS* broken!
--
Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member
CEO,
Tim Bradshaw
> I think a more accurate summary would be "Don't plan ahead."
To be fair, very many software engineering disasters can be at least
partly blamed on excessive planning - that's basically what the
waterfall model is, and we all know how well that does. XP/agile
approaches which involve some kind of minimal-planning do seem to be
better, when they can be applied (agreement from the client seems to be
the hard bit). Personally, I tend to spend way too much time thinking
of all the nasties that might bite me with the result that I deliver
really nicely engineered, bug-free things, but late and most of the
issues would never happen anyway. Forcing oneself not to plan ahead
sometimes is useful.
In the case of LD_LIBRARY_PATH though, I agree: setting it globally
seriously sucks. I wrote a little package called skel which avoids
just this issue by wrapping recalcitrant applications with a little
sh/perl script which allows you to do all sorts of environment
manipulations for them.
--tim
Richard B. gilbert
> On Sun, 25 Mar 2007, ThanksButNo wrote:
>
>
>>My point is, some things can and *should* be global, and everyone on
>>the system can and *should* use the same environment. In those
>
>
> I couldn't agree more; it's just that LD_LIBRARY_PATH isn't one of
> those things.
>
In his particular case, it appears that LD_LIBRARY_PATH IS one of those
things.
How would you ensure that everyone on the system uses a particular set
of libraries? Can you do it without replacing Sun supplied libraries?
Or without putting your libraries where they will be overwritten by the
next patch or O/S upgrade?
Marc
> In his particular case, it appears that LD_LIBRARY_PATH IS one of those
> things.
>
> How would you ensure that everyone on the system uses a particular set
> of libraries? Can you do it without replacing Sun supplied libraries?
> Or without putting your libraries where they will be overwritten by the
> next patch or O/S upgrade?
With crle.
Giorgos Keramidas
It's not always a good idea to use LD_LIBRARY_PATH. It's not
always a good idea to use crle either.
The following is from a comment in the Makefile.master file I
originally wrote a couple of years back for one of the products
for which I wrote the Makefiles:
---------------------------------------------------------------------------
# !!! DO NOT REMOVE THE RLINK_PATH or RLINK_PATH64 OPTIONS BELOW !!!
#
# The programs of this source tree depend on being able to find the
# correct set of libraries when the runtime linker-loader of Solaris
# loads the executables. This means that $(DESTDIR)/$(prefix)/lib
# (or $(DESTDIR)/$(prefix)/lib/64 for 64-bit binaries) have to be
# first in the lookup path of the rtld. There are three easy ways to
# do this, and they are all more or less wrong:
#
# - One way is to move $(DESTDIR)/$(prefix)/lib dirs before the
# system directories that the rtld searches, using the crle(1)
# utility of Solaris. This is a huge mistake, because the rtld
# will also use the 'custom' library directories for system
# binaries. Library name collissions (i.e. libmail.so.1) of
# system libraries and product-specific libraries will then lead
# system binaries or Solaris to run with the product/custom
# version of libraries, resulting in random, weird failures.
# Not good.
#
# - Using LD_LIBRARY_PATH is not ok either, since it means that we
# can't then let anyone run the $(DESTDIR)/$(prefix)/bin binaries
# directly or that we have to request they pollute their
# environment temporarily, possibly leading to the same problems
# as above with system binaries. Not good either.
#
# - Using a wrapper script to 'launch' the binaries presents its own
# set of interesting challenges when some program has to run from
# /etc/inittab, because init no longer controls the process
# itself, but the wrapper script. This means that wrapper scripts
# have to be written *extremely* carefully to avoid problems with
# fast signal delivery (i.e. before the script has a chance to set
# up appropriate 'trap' handlers), and a host of other funny
# things. Don't go there, unless it's absolutely and unavoidably
# necessary.
#
# The best workaround I have found so far to avoid all these issues is
# to hardwire at least a small number of library directories in the
# executables themselves using the -R option of the linker. Then
# these paths are used by the runtime linker only for the specific
# binary, which is cool because that's exactly what we want. Only the
# binary that contains the non-empty R-PATH will be loaded with the
# libraries of that path. The rest will fall back to the default
# crle(1)-configured library path, or their LD_LIBRARY_PATH, and work
# as expected.
RLINK_PATH = -R$(DESTDIR)/$(prefix)/lib
RLINK_PATH64 = -R$(DESTDIR)/$(prefix)/lib/64
---------------------------------------------------------------------------
[ Yes, that's extremely verbose for a comment, but after reading
it, most of our developers agreed with me, so the extra verbosity
was totally worth it. ]
Unless I'm terribly mistaken, these are, IMHO, the points Rich
Teer was trying to make.
If have seen system binaries failing because some of them picked
up (because of a misconfigured, global LD_LIBRARY_PATHvalue) the
``/opt/product/lib/64/libmail.so.1'' library, instead of
``/usr/lib/libmail.so.1'', I'm sure you will agree with Rich's
point too :)
- Giorgos
Tim Bradshaw
<rgilb...@comcast.net> said:
> How would you ensure that everyone on the system uses a particular set
> of libraries? Can you do it without replacing Sun supplied libraries?
> Or without putting your libraries where they will be overwritten by the
> next patch or O/S upgrade?
Either you do it with crle, or (in the probably more likely case that
you only want to manipulate the library path for a certain set of
executables) you do it by manipulating the environment for those
executables with a wrapper.
--tim
Rich Teer
> How would you ensure that everyone on the system uses a particular set of
> libraries? Can you do it without replacing Sun supplied libraries? Or without
You link the home-built apps with -R pointing to the correct place.
> putting your libraries where they will be overwritten by the next patch or O/S
> upgrade?
Stick 'em in /opt/local/lib or some other place that Solaris doesn't use.
Rich Teer
> Unless I'm terribly mistaken, these are, IMHO, the points Rich
> Teer was trying to make.
You're not mistaken; those are indeed the points I was trying to make.
Paul Floyd
> On Mar 25, 11:25 am, Paul Floyd <r...@127.0.0.1> wrote:
>> On 25 Mar 2007 00:53:22 -0700, ThanksButNo <no.no.tha...@gmail.com> wrote:
>>
>> > either. None of them care to learn more Unix than is necessary to get
>> > their job done.
>>
>> With that sort of attitude, I bet your software is shit.
>
> newsgroup flame.
Happy to oblige.
> And I suppose your software is wonderfully put together with all the
> unique and wondrous attributes available from the underlying OS, and
> you follow the advice in all of Rich Teer's books to the letter.
I'd have to answer 'no' to almost all of those points. I do have a copy
of Rich's book, but it's only one of the many books that I own and have
read. However, I _will_ do everything in my power to improve our build
environment, the performance and features of our software. I hope to use
the knowledge that I've acquired and continue to acquire to that end.
If ever I felt that I didn't care to learn more so that I could do a
better job, then I'd resign forthwith, and find a vocation that I did
care about.
[snip]
> Rich Teer, bless his heart, sells Unix expertise. We don't.
AFAIK, author is only one of the irons in his fire.
> Now I'm sure you think we don't know what we're doing anyway. That's
> fine, you don't pay a nickel of our salaries.
True.
A bientot
Paul
Rich Teer
> AFAIK, author is only one of the irons in his fire.
Aye. Solaris sysadmin and C programmer for hire are another two.
--
Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member
CEO,
Thomas Dickey
> set path=($path /opt/csw/bin)
That's technically correct. However, csh is disliked by some people(*),
e.g.,
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
and Sun's csh is one of the less-recommended implementations (recalling
the excuses some people have made for providing "which" _only_ as a
script, it is particularly unsuited for this example, since that undermines
the analysis of aliases versus the path).
So a better choice of example might be the Bourne or Korn shell.
In that case, one might point out a common misuse via cut/paste
of PATH which results in the current directory as part of it, e.g.,
PATH=:/bin:/usr/bin; export PATH
which is the same as
PATH=.:/bin:/usr/bin; export PATH
(*) I use tcsh for command-line stuff often - though mostly I'm using
a directory editor - why walk, when you can ride?
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Thomas Dickey
> Giving people bad advice in an ng like this is always likely to stir up
> somewhat heated replies.
It's expected -
http://www.quotationspage.com/quote/27601.html
(and, no - I don't expect to see people thinking aloud in this group)
XNOR
> On Mar 24, 2:46 pm, "XNOR" <meliksah.kara...@gmail.com> wrote:
>
>
>
>
>
> > On 24 Mart, 20:15, "gerryt" <lepsys...@gmail.com> wrote:
>
> > > On Mar 23, 2:57 pm, "XNOR" <meliksah.kara...@gmail.com> wrote:
>
> > > > I type;
> > > > #/opt/csw/bin/mc
> > > > The following message is shown:
> > > > #ld.so.1:mc:fatal:libintl.so.3:open failed: No such file or directory
> > > > Killed
> > > > actualy there is a file, /opt/csw/bin/mc
>
> > > Where did this mc come from? pkg-get should install dependencies for
> > > package "mc".
> > > If ld cannot locate it then the install is borked or the package is.
> > > On the SPARC platform
> > > the mc package installs fine. I suspect the x86 package installs fine
> > > as well.
>
> > > mc is not a GUI - its more like a curses app. So I think you wont like
> > > it even if you finally get it working : /
> > I got it fromwww.blastwave.comandcan locate mc.
>
> But mc cannot load at least one pre-requisite library. This is wrong
> and broken. I dont even know how you can accomplish that feat.
>
> > I am constant to get working it and I am not going to give up until it works.
>
> Well thats good but It should be working already. A simple:
> # pkg-get -i mc
> is all thats needed assuming you installed pkg-get correctly,
> have some thing of sane exportable PATH, and (optionally)
> edited /opt/csw/etc/pkg-get.conf to suit.
>
> A simple example PATH for bash and blastwave usage:
>
> # wipe inherited PATH clean
> PATH=""
> # Just in case export PATH. No harm done
> export PATH=/usr/sfw/bin:/bin:/sbin:/usr/openwin/bin:/usr/sbin:/usr/
> ccs/bin:/usr/dt/bin:/opt/csw/bin
>
> Save to /.xnor
>
> As root:
> # exec bash
> type:
> . /.xnor
>
> Now what happens when you try to run "mc"??- Alıntıyı gizle -
>
> - Alıntıyı göster -
Hello Gerry,
I did what u advised. mc didn't worked but setting paths carried me
forward. While I was changing PATH variables, I lost the control of my
Solaris and had to reinstall.
Yesterday, I installed 5 times my Solaris. The 5'th installation was
successful.
After installation, I read many articles and checked www.blastwave.org
again. I saw that there are many libraries which needs to each other,
glib2, ggettext, slang, common, libiconv etc.
There is a great command / parametre for pkg-get, #pkg-get -i mc >>>
Probably you already know that this command/parametre installs mc and
its depencies and necessary libraries. It's a great possiblity that my
problem was that related with necessary libraries weren't installed
correctly.
...anyway.
On my new installed clean Solaris;
1)I installed pkg-get_3.7.4.pk g
2)I entered following command regarding your advise;
#export PATH=/usr/sfw/bin:/sbin:/usr/openwin/bin:/usr/sbin:/usr/ccs/
bin:/usr/dt/bin:/opt/csw/bin
3)Then the last command: #pkg-get -i mc
:)
I have a working Midnight Commander now :)
thank you all very much for your advises.
Meliksah
XNOR
> On 24 Mar 2007 14:27:28 -0700, XNOR <meliksah.kara...@gmail.com> wrote:
>
> > Should I enter following command?
> > #set path=(. /opt/csw/bin/)
>
> No. Don't put . in your path. And append/prepend /opt/csw/bin:
>
> set path=($path /opt/csw/bin)
>
> Paul
Hello,
I put similiar commands and then as I am new for Solaris, I lost the
control of my Solaris and had to reinstall it (5 times).
:)
regards
Meliksah
XNOR
> On Mar 24, 8:07 pm, Rich Teer <rich.t...@rite-group.com> wrote:
>
> > On Sat, 24 Mar 2007, ThanksButNo wrote:
> > > I generally set it in /etc/profile, unless you're using csh.
>
> > That's about the worst possible place you could put it! Bascially,
> > you're fscking up the environment of all your users. Putting it in
> > your .profile is almost as bad, but at least then only your user's
> > environment gets FUBARed.
>
> > Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member
>
> environments.
>
> I'm used to running a homogeneous customer environment, where each and
> every user on the machine is there for exactly one purpose -- to run
> the one or more applications provided for them by our company.
>
> Indeed, under such circumstance, /etc/profile is the perfect place to
> put controls for where to find things. When something changes, you
> only have the one file that needs to be updated.
>
> No, our users don't change their home .profile. We don't let them.
> They don't have different values for LD_LIBRARY_PATH. There's no
> need.
>
> As a matter of fact, our developers don't change their own .profile
> either. None of them care to learn more Unix than is necessary to get
> Within the global /etc/profile, no one needs to worry about where
> Oracle is located, or Sybase, or TeleUSE, or gcc, or any of a dozen
> other utilities we use. And if I need to move Sybase to a new
> location, or upgrade everyone to a new version while keeping the old
> one for historical or comparison purposes, again, I only need to
> update the environment in a single location.
>
> And if I do it right, no one is the wiser. Everybody's scripts,
> everybody's programs, everything works just the way it did before,
> even with half the planet moved.
>
> Yah, if I do it wrong, then I "fsck it up" for everybody. But it
> doesn't take long to discover the mistake and rectify it. Somebody
> will try to run something and it will fail, and I'll get an
> interesting batch of e-mails and phone calls.
>
> As I said before -- I never thought something so simple could generate
> so much controversy. Sheesh.
Hello All,
I read some words in your messages that you talk about "users".
Do you use Solaris on client computers on desktops ?
I am system engineer in Turkia and using many different systems here.
Solaris is never being used as user operating system on desktops here.
Solaris is used only for Oracle, storage/backup management, backup
library management or something like that.
Is it different in your countries?
Regards
Meliksah
gerryt
> On 25 Mart, 02:27, "gerryt" <lepsys...@gmail.com> wrote:
> > As root:
> > # exec bash
> > type:
> > . /.xnor
> > Now what happens when you try to run "mc"??- Alýntýyý gizle -
> > - Alýntýyý göster -
I did?
> I have a working Midnight Commander now :)
> thank you all very much for your advises.
Im glad things worked out. And that you stuck with it and stayed on
topic : >
XNOR
Yes, u did :)
I have one more question.
I just noticed that this Solaris thing forgets what I typed in path
command after I restart it.
Where should I enter or what should I enter on terminal for my PATH
variables to keep them constant?
Regards
Meliksah
Richard B. gilbert
Solaris is used as a desktop operating system in many places. It is
also, of course, used as a server operating system for Oracle, Sybase,
etc. One of my former employers used Solaris 8 and Solaris 9 on desktop
X86 systems that were running a typesetting application. The business
sold stationery, business cards, checks, and anything else the could
print your name and address on.
Richard B. gilbert
> On 27 Mart, 03:57, "gerryt" <lepsys...@gmail.com> wrote:
>
>>On Mar 26, 5:43 pm, "XNOR" <meliksah.kara...@gmail.com> wrote:
>>
>>
>>>On 25 Mart, 02:27, "gerryt" <lepsys...@gmail.com> wrote:
>>>
>>>>As root:
>>>># exec bash
>>>>type:
>>>>. /.xnor
>>>
>>I did?
>>
>>
>>>I have a working Midnight Commander now :)
>>>thank you all very much for your advises.
>>
>>Im glad things worked out. And that you stuck with it and stayed on
>>topic : >
>
>
> Yes, u did :)
> I have one more question.
> I just noticed that this Solaris thing forgets what I typed in path
> command after I restart it.
> Where should I enter or what should I enter on terminal for my PATH
> variables to keep them constant?
>
> Regards
> Meliksah
>
It depends on what shell you are using:
korn .kshrc
sh .profile
csh .cshrc
I think that's right. Korn shell is the shell I use. That and sh when
working as root. csh also has a .login and that is about all I remember
about csh.
XNOR
wrote:
> XNOR wrote:
> > On 27 Mart, 03:57, "gerryt" <lepsys...@gmail.com> wrote:
>
> >>On Mar 26, 5:43 pm, "XNOR" <meliksah.kara...@gmail.com> wrote:
>
> >>>On 25 Mart, 02:27, "gerryt" <lepsys...@gmail.com> wrote:
>
> >>>>As root:
> >>>># exec bash
> >>>>type:
> >>>>. /.xnor
>
> >>I did?
>
> >>>I have a working Midnight Commander now :)
> >>>thank you all very much for your advises.
>
> >>Im glad things worked out. And that you stuck with it and stayed on
> >>topic : >
>
> > Yes, u did :)
> > I have one more question.
> > I just noticed that this Solaris thing forgets what I typed in path
> > command after I restart it.
> > Where should I enter or what should I enter on terminal for my PATH
> > variables to keep them constant?
>
> > Regards
> > Meliksah
>
> It depends on what shell you are using:
> korn .kshrc
> sh .profile
> csh .cshrc
> I think that's right. Korn shell is the shell I use. That and sh when
> working as root. csh also has a .login and that is about all I remember
>
> - Alıntıyı göster -
My Solaris start with sh (#) then it JDI is opened. When I need to run
something on terminal , as I don't like to use # (sh) , I am typing
bash and use bash instead of sh.
Meliksah
XNOR
> > On 27 Mart, 03:57, "gerryt" <lepsys...@gmail.com> wrote:
>
> >>On Mar 26, 5:43 pm, "XNOR" <meliksah.kara...@gmail.com> wrote:
>
> >>>On 25 Mart, 02:27, "gerryt" <lepsys...@gmail.com> wrote:
>
> >>>>As root:
> >>>># exec bash
> >>>>type:
> >>>>. /.xnor
>
> >>I did?
>
> >>>I have a working Midnight Commander now :)
> >>>thank you all very much for your advises.
>
> >>Im glad things worked out. And that you stuck with it and stayed on
> >>topic : >
>
> > Yes, u did :)
> > I have one more question.
> > I just noticed that this Solaris thing forgets what I typed in path
> > command after I restart it.
> > Where should I enter or what should I enter on terminal for my PATH
> > variables to keep them constant?
>
> > Regards
> > Meliksah
>
> It depends on what shell you are using:
> korn .kshrc
> sh .profile
> csh .cshrc
> I think that's right. Korn shell is the shell I use. That and sh when
> working as root. csh also has a .login and that is about all I remember
>
> - Alıntıyı göster -
I think, my default shell is SH.
Meliksah
Richard B. gilbert
Then find out which initialization script bash uses and define your PATH
there.
Giorgos Keramidas
> Hello All,
> I read some words in your messages that you talk about "users".
> Do you use Solaris on client computers on desktops ?
Yes.
> I am system engineer in Turkia and using many different systems here.
> Solaris is never being used as user operating system on desktops here.
> Solaris is used only for Oracle, storage/backup management, backup
> library management or something like that.
>
> Is it different in your countries?
Solaris is fine for the sort of applications you mentioned.
It is also a quite stable, performing, and clean system to run on a UNIX
workstation. It can run legacy X11 software, CDE applications, the
GNOME or KDE desktop environments, and a lot more. It includes a large
collection of freely distributable software, including such famous
programs as Emacs, vim; it can be used to develop programming languages
such as C, C++, Fortran, LISP, Perl, Python or Ruby; it can be used as a
developer workstation, including tools for building, debugging,
profiling and building complete, standalone, full releases of Solaris
package-based distributions of software.
It's hardly an OS/environment that can only fit the storage/backup or
database server model.
- Giorgos
gerryt
> On 27 Mart, 03:57, "gerryt" <lepsys...@gmail.com> wrote:
> > On Mar 26, 5:43 pm, "XNOR" <meliksah.kara...@gmail.com> wrote:
> > > On 25 Mart, 02:27, "gerryt" <lepsys...@gmail.com> wrote:
> > > > As root:
> > > > # exec bash
> > > > type:
> > > > . /.xnor
> > > > Now what happens when you try to run "mc"??- Alýntýyý gizle -
> > > > - Alýntýyý göster -
> > I did?
> > > I have a working Midnight Commander now :)
> > > thank you all very much for your advises.
> > Im glad things worked out. And that you stuck with it and stayed on
> > topic : >
Well, we are not on topic anymore.
> Yes, u did :)
Ah.. I thought that might be Turkish, never seen a word with 4 y's in
it tho' : >
> I have one more question.
Actually you have many Im sure. A new posting with a new thread
is better than this run away conversation assuming you arent
asking a question that been answered 100s of times already...
> I just noticed that this Solaris thing forgets what I typed in path
> command after I restart it.
Of course. My example was intentionally temporary.
> Where should I enter or what should I enter on terminal for my PATH
> variables to keep them constant?
That is shell dependant.
I see you use the root account a lot. People new to UNIX should
probably
avoid that whenever possible and use su when you need root jobs done.
man su
I dont like to change the root shell so I create source scripts
specifically
to address different requirements.
Say you prefer bash instead of /bin/sh as most people do.
I have a .bashrc or .bash_profile or .profile file with an appropriate
environment set up. Most env variables must be "exported" if they
arent
already. A simple example was in .xnor. Change its name to /.bashrc.
Type exec bash as root. Thats it.
man bash
I think you need to get a "UNIX for dummies" book and read up.
I dont have any suggestions for books. When I started there were none
to be had.
Learn how to search for stuff like this in Usenet archives or Google
etc.
These kind of questions have been answered for 20+ years over and
over : >
Henry Townsend
> If have seen system binaries failing because some of them picked
> up (because of a misconfigured, global LD_LIBRARY_PATHvalue) the
> ``/opt/product/lib/64/libmail.so.1'' library, instead of
> ``/usr/lib/libmail.so.1'', I'm sure you will agree with Rich's
> point too :)
I am firmly in the "don't set LD_LIBRARY_PATH" globally camp myself.
However, with that said, the particular problem you speak of here is
orthogonal; it arises from using LD_LIBRARY_PATH instead of
LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64. So to me there are two rules
for LD_LIBRARY_PATH:
1. Don't set it globally.
2. When you do use it, even in a wrapper script, use the _{32,64}
variants instead. LD_LIBRARY_PATH per se should be considered obsolete
and supported for backward compatibility only.
Actually, and getting pretty far off topic, what I do (in a wrapper
script for a specific application with a specific need which runs on
multiple platforms) is set the _{32,64} variants and then assign
LD_LIBRARY_PATH=$LD_LIBRARY_PATH_32. Since LD_LIBRARY_PATH_32 overrides
LD_LIBRARY path, LD_LIBRARY_PATH becomes a no-op on Solaris. But when
you come to Linux and other 32-bit-only environments the _{32,64}
versions are meaningless and LD_LIBRARY_PATH takes over.
HT
Thomas Dickey
>> Indeed, adjusting LD_LIBRARY_PATH is often in the installation
> Yeah, probably 'cause the developers of said software have it
> set in their environment all the time, and don't think of the
> consequences. Please see the "Linking With Libraries" section
> of this document I wrote for more:
But there is no "more" in that url (certainly less than other people on this
thread have provided - perhaps you can read some of the thread and get some
insight).
It simply repeats a few times that there is only one correct way to do things
(and that in turn is left vague ;-).
In case you haven't read your page recently, here's what it says:
The problem with -L is that it is only used when the program is
linked. The loader needs to be able to find the libraries at runtime.
The correct way to do this is to set the library run path, by passing
the -R flag to the linker, using the same syntax as the -L flag. The
incorrect way to do this is to set the LD_LIBRARY_PATH environment
variable to the appropriate location. Unfortunately, a lot of software
relies on this method of locating libraries. This problem is easily
remedied for programs for which we have the source. We can simply edit
the Makefile and rebuild it. For commercial applications, we must
petition the vendor to build future versions of their programs
correctly.
We should point out that there is one legitimate use of
LD_LIBRARY_PATH: when we are developing a new version of a library. We
can then use the environment variable to override the compiled-in run
path. We can run our (correctly linked) programs with LD_LIBRARY_PATH
unset, which will use the current version of the library, and then set
it to our development area when we are ready to test the new version
of the library. For the sake of emphasis, it is worth repeating that
we should not set LD_LIBRARY_PATH in our session start-up scripts (for
example, .profile or .login). If a program to which we do not have the
source relies on LD_LIBRARY_PATH, we should write a wrapper script
that sets it before invoking the desired program.