Home > Archive > Unix Programming > June 2005 > Shared Libraries : library paths ??
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Shared Libraries : library paths ??
|
|
| john.maximus@gmail.com 2005-06-06, 3:58 pm |
| Hi,
I have downloaded some package. i used ./configure, make and make
install.
my friend has told me that the libraries created will have library
paths embedded in them. ie programs will work only if the libraries
are at specific places. in this case my home directory. is it true.
how to avoid it.
I also saw while compiling a line which states:
Checking how to hardcode library paths into programs ... immediate
what does this mean ?.
Regards,
/J
| |
| Phil Endecott 2005-06-06, 3:58 pm |
| john.maximus@gmail.com wrote:
> Hi,
> I have downloaded some package. i used ./configure, make and make
> install.
>
> my friend has told me that the libraries created will have library
> paths embedded in them. ie programs will work only if the libraries
> are at specific places. in this case my home directory. is it true.
I suggest looking at the libtool documentation. You will quickly learn
that this is a horribly complicated problem that is different on
different platforms, with different compilers etc.
The libraries that you have in your home directory probably don't have
paths embedded in them. The difficulty is with executables that link
against these libraries. In order to know where the libraries are at
run time, they can either (a) have the path to your home directory
included in them, or (b) require you to set LD_LIBRARY_PATH at run time
to point to them, or (c) require you to edit /etc/ld.so.conf to point to
them.
--Phil.
| |
| phil-news-nospam@ipal.net 2005-06-06, 8:57 pm |
| In comp.os.linux.development.system Phil Endecott <phil_nn05@chezphil.org> wrote:
| I suggest looking at the libtool documentation. You will quickly learn
| that this is a horribly complicated problem that is different on
| different platforms, with different compilers etc.
It seems when a tool is meant to be able to do everything for everyone,
it tends to become easy for no one. I personally avoid libtool.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
| |
| Peter T. Breuer 2005-06-06, 8:57 pm |
| In comp.os.linux.development.system phil-news-nospam@ipal.net wrote:
> In comp.os.linux.development.system Phil Endecott <phil_nn05@chezphil.org> wrote:
> | I suggest looking at the libtool documentation. You will quickly learn
> | that this is a horribly complicated problem that is different on
> | different platforms, with different compilers etc.
> It seems when a tool is meant to be able to do everything for everyone,
> it tends to become easy for no one. I personally avoid libtool.
Like the plague. Amen. I really fail to see what problem it purports to
solve .. since when is there a common unix platform without dynamically
loadable libraries that are expected to be found in /usr/lib or similar?
And if there is one, will someone please shoot it? I really don't want
it to exist.
Peter
| |
| Måns Rullgård 2005-06-07, 3:57 am |
| ptb@lab.it.uc3m.es (Peter T. Breuer) writes:
> In comp.os.linux.development.system phil-news-nospam@ipal.net wrote:
>
>
>
> Like the plague. Amen. I really fail to see what problem it purports to
> solve .. since when is there a common unix platform without dynamically
> loadable libraries that are expected to be found in /usr/lib or similar?
>
> And if there is one, will someone please shoot it? I really don't want
> it to exist.
Take a look at Linux, *BSD, Solaris, AIX, HP-UX, Tru64, and whatever
else you have access to. Then come back and tell me if you found
anything they all had in common with respect to shared libraries.
--
Måns Rullgård
mru@inprovide.com
| |
| phil-news-nospam@ipal.net 2005-06-07, 3:57 am |
| In comp.os.linux.development.system M?ns Rullg?rd <mru@inprovide.com> wrote:
| ptb@lab.it.uc3m.es (Peter T. Breuer) writes:
|
|> In comp.os.linux.development.system phil-news-nospam@ipal.net wrote:
|>> In comp.os.linux.development.system Phil Endecott <phil_nn05@chezphil.org> wrote:
|>
|>> | I suggest looking at the libtool documentation. You will quickly learn
|>> | that this is a horribly complicated problem that is different on
|>> | different platforms, with different compilers etc.
|>
|>> It seems when a tool is meant to be able to do everything for everyone,
|>> it tends to become easy for no one. I personally avoid libtool.
|>
|> Like the plague. Amen. I really fail to see what problem it purports to
|> solve .. since when is there a common unix platform without dynamically
|> loadable libraries that are expected to be found in /usr/lib or similar?
|>
|> And if there is one, will someone please shoot it? I really don't want
|> it to exist.
|
| Take a look at Linux, *BSD, Solaris, AIX, HP-UX, Tru64, and whatever
| else you have access to. Then come back and tell me if you found
| anything they all had in common with respect to shared libraries.
Are they so _radically_ different that it takes something like libtool
to get a library to successfully build on these platforms?
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
| |
| Paul Pluzhnikov 2005-06-07, 3:57 am |
| phil-news-nospam@ipal.net writes:
> In comp.os.linux.development.system M?ns Rullg?rd <mru@inprovide.com> wrote:
> | Take a look at Linux, *BSD, Solaris, AIX, HP-UX, Tru64, and whatever
> | else you have access to. Then come back and tell me if you found
> | anything they all had in common with respect to shared libraries.
They all have the concept of shared libraries, but that's about it :-)
> Are they so _radically_ different that it takes something like libtool
> to get a library to successfully build on these platforms?
You don't have to use libtool, and in fact libtool (last I looked
at it) did not build correct AIX shared libraries, when used with
the native compiler.
However, if you don't use libtool, you better have access to the
platform, be experienced on it, and your makefile will not look
pretty :-(
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Peter T. Breuer 2005-06-07, 3:57 am |
| In comp.os.linux.development.system M?ns Rullg?rd <mru@inprovide.com> wrote:
> ptb@lab.it.uc3m.es (Peter T. Breuer) writes:
[color=darkred]
> Take a look at Linux, *BSD, Solaris, AIX, HP-UX, Tru64, and whatever
> else you have access to. Then come back and tell me if you found
Well, AIX and Tru64 I have never used. The others I am or have been
totally familiar with. They don't need any "help" from libtool at all,
since they use dynamic libraries searched for in /usr/lib. What is the
precise point you are making here?
> anything they all had in common with respect to shared libraries.
As far as I know, if you compile with gcc on these platforms, it
suffices to do
gcc -o foo foo.o -lbar
in order to get an executable foo that is dynamically linked against
whatever /usr/lib/libbar.so pints to. Where is the problem?
Peter
| |
| Paul Pluzhnikov 2005-06-07, 3:57 am |
| ptb@lab.it.uc3m.es (Peter T. Breuer) writes:
> Where is the problem?
The problem that libtool is trying to solve is how to *build*
shared libraries on all the various platforms.
One answer is 'gcc -shared ...', but if you do not want to have
libgcc_s.so dependency, or are building C++ with a need to run
global initializers, or are building with the aCC compiler, things
quickly get complicated.
> Well, AIX and Tru64 I have never used.
And AIX'x shared library model is unlike any other UNIX (much closer
to Win32 actually). So you've just eliminated half of the problem
space. Sure, you don't need anything more complicated then
'gcc -shared' if all you are targeting is straight C on Linux.
But that's not what libtool was created for.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Peter T. Breuer 2005-06-07, 3:57 am |
| In comp.os.linux.development.system Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote:
> ptb@lab.it.uc3m.es (Peter T. Breuer) writes:
[color=darkred]
> The problem that libtool is trying to solve is how to *build*
> shared libraries on all the various platforms.
Well, OK. gcc -shared -o libfoo.so.1.2 -Wl,-soname=libfoo.so.1 *.o
is what I'd do. If you don't have gcc or gnu ld, then one needs to read
the man page for the local linker and/or compiler. But as far as I
recall things were prety much the same under Sun's linkers, and HP's.
And the *bsd use gnu. And anyway "compile gnu toolchain first" works.
So on a linux platform, or a *bsd one, and probably a Sun platform (not
that I am up to date), I don't see the slightest need.
> One answer is 'gcc -shared ...', but if you do not want to have
> libgcc_s.so dependency,
?? I never have it. Does your gcc emit code which calls special
functions? Oh - it seems to be part of gcc 3.*. I don't use modern
gcc. Where's the .a version?
> or are building C++ with a need to run
> global initializers,
Double dutch to me. Global initializers? You mean global static
objects (which would get created and hence initialized by their
constructor before runtime)? I don't see what extra this needs.
> or are building with the aCC compiler, things
That different compilers have different syntax is not something one can
get around. It's a fact. I fail to see why one should expect that
different linkers don't also have different syntax and deal with it!
libtool seems to be an attempt at a frontend for umpteen different
linkers ... pshawwwww. Fair enough, but just LART the lauthors until
they agree on a reasonable syntax if it bothers you. Isn't this
posix-ized?
> quickly get complicated.
[color=darkred]
> And AIX'x shared library model is unlike any other UNIX (much closer
> to Win32 actually). So you've just eliminated half of the problem
Good.
> space. Sure, you don't need anything more complicated then
> 'gcc -shared' if all you are targeting is straight C on Linux.
> But that's not what libtool was created for.
Then why use it? Let the AIX people build a compatibility frontend.
The idea of fontending umpteen linkers when they practically all
work the same anyway is just daft. Let the platforms with a problem mend
their problem by providing a compatibility frontend. Everyone else
can just be happy.
Peter
| |
| Lawrence D¹Oliveiro 2005-06-07, 3:57 am |
| In article <g5ven2-gpu.ln1@news.it.uc3m.es>,
ptb@lab.it.uc3m.es (Peter T. Breuer) wrote:
>.. since when is there a common unix platform without dynamically
>loadable libraries that are expected to be found in /usr/lib or similar?
>
>And if there is one, will someone please shoot it? I really don't want
>it to exist.
I would like to see non-ANSI C compilers shot as well, but it seems some
UNIX systems still run them...
| |
| Paul Pluzhnikov 2005-06-07, 3:57 am |
| ptb@lab.it.uc3m.es (Peter T. Breuer) writes:
>
> Well, OK. gcc -shared -o libfoo.so.1.2 -Wl,-soname=libfoo.so.1 *.o
This is *not* a solution to the problem libtool is trying to solve,
because the above command will fail on all non-ELF platforms.
> Let the AIX people build a compatibility frontend.
Your solution to the problem that libtool is trying to solve
(paraphrased):
I am not going to solve this problem. I'll wait till someone else
(mythical "AIX people") solves it for me.
I should try this with my boss sometime :-)
> The idea of fontending umpteen linkers when they practically all
> work the same anyway is just daft.
But they don't all work the same, that's the point.
And if "AIX people" do come up with a "compatibility frontend",
how is this any different from what libtool is trying do?
> Everyone else can just be happy.
Paraphrasing: "My software builds on Linux; be happy. If you must
run on AIX, tough luck, XXXXX to "AIX people" and be happy anyway" [1] :-)
Cheers,
[1] I wonder how happy you'll be if 'gcc people' were to adopt the
same attitude.
P.S. I don't actually defend libtool -- I dislike it quite a bit.
I am just stating the problem it intends to solve, which is quite
a bit more complicated then you make it appear.
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Måns Rullgård 2005-06-07, 8:58 am |
| Lawrence D¹Oliveiro <ldo@g -central.gen.new_zealand> writes:
> In article <g5ven2-gpu.ln1@news.it.uc3m.es>,
> ptb@lab.it.uc3m.es (Peter T. Breuer) wrote:
>
>
> I would like to see non-ANSI C compilers shot as well, but it seems some
> UNIX systems still run them...
If you stick to C89 you should have very few problems. C99 is not
quite as widespread.
--
Måns Rullgård
mru@inprovide.com
| |
| Peter T. Breuer 2005-06-07, 8:58 am |
| In comp.os.linux.development.system Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote:
> ptb@lab.it.uc3m.es (Peter T. Breuer) writes:
[color=darkred]
> This is *not* a solution to the problem libtool is trying to solve,
> because the above command will fail on all non-ELF platforms.
Tough - there aren't any. To as good an approximation as I care to know
about, and linux, *bsd, sun etc are certainly not among them! Do you
think I CARE about a platform that hasn't even bothered to make itself
compatible enough to run ELF? Let them un-stone-age themselves!
[color=darkred]
> Your solution to the problem that libtool is trying to solve
> (paraphrased):
> I am not going to solve this problem. I'll wait till someone else
> (mythical "AIX people") solves it for me.
Exactly so - I am not interested in running on AIX, I am not compiling
for AIX, I am not developing for AIX, AIX is not amoong the platforms I
care about or test on. If they want to run my stuff, they can figure
out how t compile on their platform, tell me, and I'll add it to my
makefile as an ARCH=aix option, and that's it.
> I should try this with my boss sometime :-)
Go ahead. It's not your problem.
[color=darkred]
> But they don't all work the same, that's the point.
> And if "AIX people" do come up with a "compatibility frontend",
> how is this any different from what libtool is trying do?
The right people are doing it, in the right place, and libtool is out
of my face.
[color=darkred]
> Paraphrasing: "My software builds on Linux; be happy. If you must
> run on AIX, tough luck, XXXXX to "AIX people" and be happy anyway" [1] :-)
Exactly. If they are so interested in having my stuff, let them develop
a libtool -like frontend so that my stuff may compile on their platform.
It is not reasonable to expect me too use a nonsense frontend on all
OTHER platforms.
> [1] I wonder how happy you'll be if 'gcc people' were to adopt the
> same attitude.
> P.S. I don't actually defend libtool -- I dislike it quite a bit.
> I am just stating the problem it intends to solve, which is quite
> a bit more complicated then you make it appear.
The problem it solves is that AIX needs a nonstandard way of making
shared libraries, according to you. Therefore it is an AIX problem,
and I will thank the AIX people for including it in their toolchain and
I will call it when on AIX. FOr linux and anything else normal I don't
want to see it.
Peter
| |
| Måns Rullgård 2005-06-07, 8:59 am |
| ptb@lab.it.uc3m.es (Peter T. Breuer) writes:
> In comp.os.linux.development.system Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote:
>
>
>
> Tough - there aren't any. To as good an approximation as I care to know
> about, and linux, *bsd, sun etc are certainly not among them! Do you
Tru64, at least up to v5.0, uses ECOFF.
> think I CARE about a platform that hasn't even bothered to make itself
> compatible enough to run ELF? Let them un-stone-age themselves!
The whole idea is that your programs will compile and run out of the
box, on platforms you have never heard of, without you needing to care
about it.
--
Måns Rullgård
mru@inprovide.com
| |
| Henry Townsend 2005-06-07, 8:59 am |
| Måns Rullgård wrote:
>
>
> Tru64, at least up to v5.0, uses ECOFF.
>
>
>
>
> The whole idea is that your programs will compile and run out of the
> box, on platforms you have never heard of, without you needing to care
> about it.
Mac OSX, which is almost certainly one of the 3 or 4 most "popular" (in
the sense of concurrently-booted kernels) Unices, uses mach-o. I wish
they'd use ELF myself, and with 10.4 the L&F is much more like ELF, but
it's not ELF. Say what you want about OSX but it's not stone-age and
it's not going away anytime soon.
--
Henry Townsend
| |
| Peter T. Breuer 2005-06-07, 4:02 pm |
| In comp.os.linux.development.system M?ns Rullg?rd <mru@inprovide.com> wrote:
> The whole idea is that your programs will compile and run out of the
> box, on platforms you have never heard of, without you needing to care
> about it.
I'm sorry - if they are not bothered to make reasonable efforts to make
themselves even roughly compatible with the rest of the world, then
phooie to them. Their packagers can develop the expertise in
repackaging code for them, not me.
Peter
| |
| Peter T. Breuer 2005-06-07, 4:02 pm |
| In comp.os.linux.development.system Henry Townsend <henry.townsend@not.here> wrote:
> Mac OSX, which is almost certainly one of the 3 or 4 most "popular" (in
> the sense of concurrently-booted kernels) Unices, uses mach-o. I wish
> they'd use ELF myself, and with 10.4 the L&F is much more like ELF, but
> it's not ELF. Say what you want about OSX but it's not stone-age and
> it's not going away anytime soon.
Same holds. I am not writing for MAC. If they (or whoever) want to
port stuff to their platform, let their packagers do it, not me.
Peter
| |
| Zeljko Vrba 2005-06-07, 4:02 pm |
| On 2005-06-07, Måns Rullgård <mru@inprovide.com> wrote:
> ptb@lab.it.uc3m.es (Peter T. Breuer) writes:
>
>
>
> The whole idea is that your programs will compile and run out of the
> box, on platforms you have never heard of, without you needing to care
> about it.
>
Unfortunately, it doesn't. configure breaks *badly* on i386-interix platform.
I know this thread is not about autoconf, but libtool is in the same set of
tools. I'm bitching about autoconf here because this post goes on at least
one gnu.* group. Out of principle, I'm personally not using it in none of my
open-source projects.
The rest of this article is autoconf rant. This is a head-on warning so
you can't call me a troll :)
Right at the start it complains it doesn't know about 'i386-interix' and stops.
What's that you might ask? Well, you get it from uname -a when you install
Microsoft's excellent SFU (services for unix).
Not to mention that, when I set some 'sane' unix system (MS claims SFU is
derived from OpenBSD code base) that it happily reports that there is no
open(2), fork(2), etc.. which _is_ present in SFU. It is unable to deduce
that CFLAGS need -D_ALL_SOURCE.
I've seen stupid autoconf scripts break too many times, and not once have
I hacked configure to persuade it to accept lower 3rd minor version number of
some library than what the author used..
Autoconf is 'evil'. If you are able to interpret its error messages when it
complains about something, then you are also able to edit some header and/or
makefile. Without trying to figure out what is happening when it breaks.
Ergo, there is no point for its very existence.
I mean, what's the point of configure scripts which work correctly only
on linux (and I've seen such..)
Not to mention zillion versions of autoconf and you need a particular one
if you want to regenerate configure script from configure.in.
And libtool is a tremendously large script that sometimes takes longer to start
up than the actual linking process of smaller programs. Which really is
annoying when you are developing smaller programs and compiling/linking
frequently.
All in all, I consider autoconf, libtool (and possibly other SW in that
category) an abomination.. the worst SW ever published by GNU/FSF. I believe
it was written in good intentions, but.. you know what they say: the road to
hell is paved with good intentions.
| |
| phil-news-nospam@ipal.net 2005-06-07, 4:02 pm |
| In comp.os.linux.development.system Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote:
| phil-news-nospam@ipal.net writes:
|
|> In comp.os.linux.development.system M?ns Rullg?rd <mru@inprovide.com> wrote:
|
|> | Take a look at Linux, *BSD, Solaris, AIX, HP-UX, Tru64, and whatever
|> | else you have access to. Then come back and tell me if you found
|> | anything they all had in common with respect to shared libraries.
|
| They all have the concept of shared libraries, but that's about it :-)
|
|> Are they so _radically_ different that it takes something like libtool
|> to get a library to successfully build on these platforms?
|
| You don't have to use libtool, and in fact libtool (last I looked
| at it) did not build correct AIX shared libraries, when used with
| the native compiler.
|
| However, if you don't use libtool, you better have access to the
| platform, be experienced on it, and your makefile will not look
| pretty :-(
What I do now is generate a Makefile using a script I wrote. It just
behaves quite differently from things like autoconf and libtool. My
Makefile actually looks quite pretty ... in an insane sort of way due
to the fact that it is one big flat Makefile for the entire source tree.
It also builds the Makefile so that make is to be run in a directory
containing only the Makefile; it references the source by longer paths
to the directory where the source is extracted, never writing anything
there (so it can compile straight from a read/only mount, for example).
But it could look "ugly" to someone unfamiliar with my approach.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
| |
| phil-news-nospam@ipal.net 2005-06-07, 4:02 pm |
| In comp.os.linux.development.system Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote:
| Paraphrasing: "My software builds on Linux; be happy. If you must
| run on AIX, tough luck, XXXXX to "AIX people" and be happy anyway" [1] :-)
Many people avoid the effort needed to make their software run on
Microsoft Windows. Just because Windows does not try to be like
Unix, and AIX does, is that sufficient reason to increase the effort
to make a library portable to AIX?
When we talk about portability, it needs to be qualified in scope.
Software that works on all Unix-like systems gets labeled portable
even if it does not work on Windows or other operating systems.
I presently have no access to AIX so I really cannot test my latest
library. But many years ago I did, and when I simply dropped in my
code and compiled it on AIX, it compiled error free, built error free,
and worked just fine on AIX. But AIX was quite new then, and there
was no Linux at the time.
Now days, I'm happy if my library builds on all major distributions
of Linux, and the big BSDs. Getting it working on AIX, HP/UX, Solaris,
etc, is a plus ... which I am less concerned about over time.
| P.S. I don't actually defend libtool -- I dislike it quite a bit.
| I am just stating the problem it intends to solve, which is quite
| a bit more complicated then you make it appear.
I think the complications tend to be concentrated in a few places.
My goals generally exclude those places, unless there is some good
reason to go there (which I could do in exchange for a couple free
machines).
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
| |
| phil-news-nospam@ipal.net 2005-06-07, 4:02 pm |
| In comp.os.linux.development.system Peter T. Breuer <ptb@lab.it.uc3m.es> wrote:
| In comp.os.linux.development.system Henry Townsend <henry.townsend@not.here> wrote:
|> Mac OSX, which is almost certainly one of the 3 or 4 most "popular" (in
|> the sense of concurrently-booted kernels) Unices, uses mach-o. I wish
|> they'd use ELF myself, and with 10.4 the L&F is much more like ELF, but
|> it's not ELF. Say what you want about OSX but it's not stone-age and
|> it's not going away anytime soon.
|
| Same holds. I am not writing for MAC. If they (or whoever) want to
| port stuff to their platform, let their packagers do it, not me.
I'm quite willing to port my stuff to MAX OSX. I just need to have all
the technical details documented clearly, and 1 or 2 freebie machines.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
| |
| phil-news-nospam@ipal.net 2005-06-07, 4:02 pm |
| In comp.os.linux.development.system M?ns Rullg?rd <mru@inprovide.com> wrote:
| Lawrence D?Oliveiro <ldo@g-central.gen.new_zealand> writes:
|
|> In article <g5ven2-gpu.ln1@news.it.uc3m.es>,
|> ptb@lab.it.uc3m.es (Peter T. Breuer) wrote:
|>
|>>.. since when is there a common unix platform without dynamically
|>>loadable libraries that are expected to be found in /usr/lib or similar?
|>>
|>>And if there is one, will someone please shoot it? I really don't want
|>>it to exist.
|>
|> I would like to see non-ANSI C compilers shot as well, but it seems some
|> UNIX systems still run them...
|
| If you stick to C89 you should have very few problems. C99 is not
| quite as widespread.
I made the migration to C99 a couple years after it was out. But I still
use some GNU extensions, too, so my code still needs gcc to compile. My
goal for portability is _not_ to be 100% to every platform that claim
Unix, POSIX, or SUS compatibility ... it is just for a reasonable subset
which is probably close to 99% of the running base (excluding that great
big foot abomination from the US northwest).
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
| |
| Bjorn Reese 2005-06-07, 4:02 pm |
| Måns Rullgård wrote:
> Take a look at Linux, *BSD, Solaris, AIX, HP-UX, Tru64, and whatever
> else you have access to. Then come back and tell me if you found
> anything they all had in common with respect to shared libraries.
It's not that bad. All you need is a list of the appropriate compiler
and/or linker options for each platform/compiler you want to support.
Section 6.3 of the comp.programmer.unix FAQ is a good starting-point
(although incomplete).
http://www.erlenstar.demon.co.uk/unix/
--
mail1dotstofanetdotdk
| |
|
| [Does this need to be so heavily crossposted?]
On Tue, 7 Jun 2005, Peter T. Breuer stated:
> In comp.os.linux.development.system Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote:
>
>
> Well, OK. gcc -shared -o libfoo.so.1.2 -Wl,-soname=libfoo.so.1 *.o
> is what I'd do. If you don't have gcc or gnu ld, then one needs to read
> the man page for the local linker and/or compiler. But as far as I
> recall things were prety much the same under Sun's linkers, and HP's.
> And the *bsd use gnu. And anyway "compile gnu toolchain first" works.
That's, alas, not going to fly. :/
> So on a linux platform, or a *bsd one, and probably a Sun platform (not
> that I am up to date), I don't see the slightest need.
I also have to build shared libraries on Tru64, IRIX, HP/UX 10.20, and
AIX. Two fo these have *very* unusual shared library arrangements by
Unix standards.
MacOS X is also unusual.
>
> ?? I never have it. Does your gcc emit code which calls special
> functions?
Every version of GCC does; it's just that in old GCCs they're all in
a static library. In modern GCCs, they're in a shared library too,
and if your program or shared library uses a shared library which
is written in C++, you'll probably resolve libgcc symbols from the
shared library, not the static one.
> Oh - it seems to be part of gcc 3.*. I don't use modern
> gcc. Where's the .a version?
There *is* one (in the GCC tooldir), and you *can* force use of it, but
this is not recommended if you don't know exactly what you're doing:
you'll break exception throw/catches across shared library boundaries,
and RTTI too. (In older GCCs, doing this simply didn't work, so this is
not a regression.)
Code which makes no use of exceptions, and does not link against
libraries which make use of exceptions, will link against the static
libgcc, as ever. (If such code dlopen()s libraries which make use of
exceptions and expects cross-shared-library throws and catches to work,
it will have to explicitly say -shared-libgcc at link time. But this
is quite a rare case.)
>
> Double dutch to me. Global initializers? You mean global static
> objects (which would get created and hence initialized by their
> constructor before runtime)? I don't see what extra this needs.
It needs special support from the linker if you're going to do it in
shared libraries. Most OSes have no such support. (One of the jobs of
collect2 is to support this for executables, but the tricks it uses
cannot work for shared libraries, which have no portable analogue of
main().)
>
> That different compilers have different syntax is not something one can
> get around. It's a fact. I fail to see why one should expect that
> different linkers don't also have different syntax and deal with it!
Yes. Fixing that is (part of) libtool's job.
> libtool seems to be an attempt at a frontend for umpteen different
> linkers ... pshawwwww.
Pretty much, yes. (It also has a portable replacement for dlopen()
and friends.)
> Fair enough, but just LART the lauthors until
> they agree on a reasonable syntax if it bothers you. Isn't this
> posix-ized?
No. Your approach of `just break all the world's software' is, um,
impractical. I like being able to build free software making use of
shared libraries on many and various strange platforms (libtool even
supports *ick* Windows).
I don't like libtool either: it's horribly slow and *really* shouldn't
be a monstrous shell script... but it's a hell of a lot better than
*not* having libtool.
>
> Then why use it? Let the AIX people build a compatibility frontend.
Because you'll also have to get HP to build a compatibility frontend,
and both the AIX people and HP people are unlikely to build
compatibility frontends to versions of their OS they *aren't even
selling anymore* but which people are still using, and even if they
did, Microsoft are *really* unlikely to help out. And then there's
MacOS X...
> The idea of fontending umpteen linkers when they practically all
> work the same anyway is just daft.
They work in a variety of *radically* different ways. More than just the
command-lines differ. Any claim to the contrary betrays deep ignorance
of the field :(
For example, even Solaris and Linux/SPARC work differently, and the
Linux shared library loader was *modelled* on the Solaris one. Needed
command-line switches are radically different, and the Solaris loader
won't relocate non-PIC code in shared libraries, for starters... those
are exceptionally *similar* cases, yet libtool has to make different
decisions for them.
Shared library naming conventions and versioning also differs across
platforms in many ways, and often can't be changed at whim because the
various dynamic loaders have explicit support for the platforms'
schemes: even the BSDs and Linux differ here! We *need* an
impedance-matcher, and that's just what libtool and the automake support
for it is for.
> Let the platforms with a problem mend
> their problem by providing a compatibility frontend. Everyone else
> can just be happy.
Traditionally, waiting for proprietary software vendors to do that
is a hopeless wait: they can't coordinate well enough.
--
`It's as bizarre an intrusion as, I don't know, the hobbits coming home
to find that the Shire has been taken over by gangsta rappers.'
| |
| Måns Rullgård 2005-06-07, 4:02 pm |
| Bjorn Reese <breese@see.signature> writes:
> Måns Rullgård wrote:
>
>
> It's not that bad. All you need is a list of the appropriate compiler
> and/or linker options for each platform/compiler you want to support.
This is essentially what libtool is.
--
Måns Rullgård
mru@inprovide.com
| |
| Rich Walker 2005-06-07, 4:02 pm |
| phil-news-nospam@ipal.net writes:
>
> What I do now is generate a Makefile using a script I wrote. It just
> behaves quite differently from things like autoconf and libtool. My
> Makefile actually looks quite pretty ... in an insane sort of way due
> to the fact that it is one big flat Makefile for the entire source tree.
That's not a bad idea. After reading "Recursive Make Considered
Harmful", I moved to "scatter Component.mk files in all subdirectories
and have one Makefile in the top" and it really works for me. The
individual Component.mk files are *really* simple, modulo the need to
reference the full paths, and the reliable-build nature is wondrous.
> It also builds the Makefile so that make is to be run in a directory
> containing only the Makefile; it references the source by longer paths
> to the directory where the source is extracted, never writing anything
> there (so it can compile straight from a read/only mount, for
> example).
That's worth a modicum of toil to do :->
cheers, Rich.
>
> But it could look "ugly" to someone unfamiliar with my approach.
>
> --
> -----------------------------------------------------------------------------
> | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
> | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
> -----------------------------------------------------------------------------
--
rich walker | Shadow Robot Company | rw@shadow.org.uk
technical director 251 Liverpool Road |
need a Hand? London N1 1LX | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml
| |
| Måns Rullgård 2005-06-07, 4:02 pm |
| Rich Walker <rw@shadow.org.uk> writes:
> phil-news-nospam@ipal.net writes:
>
>
> That's not a bad idea. After reading "Recursive Make Considered
> Harmful", I moved to "scatter Component.mk files in all subdirectories
> and have one Makefile in the top" and it really works for me. The
> individual Component.mk files are *really* simple, modulo the need to
> reference the full paths, and the reliable-build nature is wondrous.
This is totally orthogonal to the question of using libtool or not.
>
> That's worth a modicum of toil to do :->
automake generated makefiles support building in a separate directory
with no additional work.
--
Måns Rullgård
mru@inprovide.com
| |
| Roger Leigh 2005-06-07, 8:58 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Måns Rullgård <mru@inprovide.com> writes:
> Lawrence D¹Oliveiro <ldo@g-central.gen.new_zealand> writes:
>
>
> If you stick to C89 you should have very few problems. C99 is not
> quite as widespread.
Unless you are using esoteric features, GCC has supported C99 quite
well for some time. Well enough for me to be using it for all my work
over the last year, at least.
Autoconf CVS has had proper C99 support autodetection since January
(AC_PROG_CC_C99). Hopefully they will make a release soon, then you
won't need to fiddle with -std=gnu99 or whatever.
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFCpee6VcFcaSW/ uEgRAkU3AKC+Vlgf9QaAdCmmj+zooAoJ3dAHcwCd
G1FW
Xm+vWoH92IcC7dMpFNxaex8=
=c4eS
-----END PGP SIGNATURE-----
| |
| Roger Leigh 2005-06-07, 8:58 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Zeljko Vrba <mo.dor@fly.srk.fer.hr> writes:
> On 2005-06-07, Måns Rullgård <mru@inprovide.com> wrote:
> Unfortunately, it doesn't. configure breaks *badly* on i386-interix platform.
Would you care to provide some examples?
> The rest of this article is autoconf rant. This is a head-on warning so
> you can't call me a troll :)
>
> Right at the start it complains it doesn't know about 'i386-interix' and stops.
> What's that you might ask? Well, you get it from uname -a when you install
> Microsoft's excellent SFU (services for unix).
Have you tried running config.guess. Perhaps you just need to
download a more recent version:
http://savannah.gnu.org/cgi-bin/vie...ig/config.guess
http://savannah.gnu.org/cgi-bin/vie...nfig/config.sub
> Autoconf is 'evil'. If you are able to interpret its error messages when it
> complains about something, then you are also able to edit some header and/or
> makefile. Without trying to figure out what is happening when it breaks.
> Ergo, there is no point for its very existence.
Nope, it just needs a little more information about your system. This
should have been provided by MS if they wanted it supporting. More
likely, you are using an older version of autoconf without Interix
support. MacOS X had the same problem a few years back; it's no big
deal.
> Not to mention zillion versions of autoconf and you need a particular one
> if you want to regenerate configure script from configure.in.
There's one version: 2.59b. Very old software might need 2.13, but if
it's not been updated in 5 years, you don't want to use it anyway.
> And libtool is a tremendously large script that sometimes takes longer to start
> up than the actual linking process of smaller programs. Which really is
> annoying when you are developing smaller programs and compiling/linking
> frequently.
Yes. This is a known problem, and libtool may be rewritten in C, or
use POSIX sh functions in the future. The latter is more likely at
this point. When you're running on Windows, the fork() overhead the
the real killer. If you need to build and run Unix code, use a real
Unix system.
> All in all, I consider autoconf, libtool (and possibly other SW in that
> category) an abomination.. the worst SW ever published by GNU/FSF. I believe
> it was written in good intentions, but.. you know what they say: the road to
> hell is paved with good intentions.
They are ugly, but the job they perform is not particularly simple or
pleasant. There are no real alternatives, and hey, m4 is fun!
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFCpeolVcFcaSW/ uEgRAq+gAJ0ZfycFW1IROR1a3E9tukfKyRFThQCd
GaKL
dFPcDObj3ejrRUr251yiKs8=
=msr7
-----END PGP SIGNATURE-----
| |
| phil-news-nospam@ipal.net 2005-06-08, 4:00 am |
| In comp.os.linux.development.system M?ns Rullg?rd <mru@inprovide.com> wrote:
| Rich Walker <rw@shadow.org.uk> writes:
|
|> phil-news-nospam@ipal.net writes:
|>
|>>
|>> What I do now is generate a Makefile using a script I wrote. It just
|>> behaves quite differently from things like autoconf and libtool. My
|>> Makefile actually looks quite pretty ... in an insane sort of way due
|>> to the fact that it is one big flat Makefile for the entire source tree.
|>
|> That's not a bad idea. After reading "Recursive Make Considered
|> Harmful", I moved to "scatter Component.mk files in all subdirectories
|> and have one Makefile in the top" and it really works for me. The
|> individual Component.mk files are *really* simple, modulo the need to
|> reference the full paths, and the reliable-build nature is wondrous.
|
| This is totally orthogonal to the question of using libtool or not.
True. This shows that threads can make 90 degree turns of topic :)
|>> It also builds the Makefile so that make is to be run in a directory
|>> containing only the Makefile; it references the source by longer paths
|>> to the directory where the source is extracted, never writing anything
|>> there (so it can compile straight from a read/only mount, for
|>> example).
|>
|> That's worth a modicum of toil to do :->
|
| automake generated makefiles support building in a separate directory
| with no additional work.
No additional work relative to what? There's no work needed to create a
config file for automake?
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
| |
| Lawrence D¹Oliveiro 2005-06-08, 8:58 am |
| In article <yw1x3bruiovx.fsf@ford.inprovide.com>,
Måns Rullgård <mru@inprovide.com> wrote:
>Lawrence D¹Oliveiro <ldo@g-central.gen.new_zealand> writes:
>
>
>If you stick to C89 you should have very few problems.
Except with systems running non-ANSI C compilers that won't accept
function prototypes, for example.
| |
| Zeljko Vrba 2005-06-08, 8:58 am |
| On 2005-06-07, Roger Leigh <${rleigh}@invalid.whinlatter.ukfsn.org.invalid> wrote:
>
> Would you care to provide some examples?
>
I don't have available the environment now.. It was a year ago at my former
work place. Now I just don't want to bother.
And I also remember autoconf generated configure breaking on Solaris sh
(not bash!) a few years ago..
Please don't ask for examples, and probably you're going to say again it
was too old version.
>
> Have you tried running config.guess. Perhaps you just need to
>
No. But how do you comment on not being able to guess about -D_ALL_SOURCE?
>
> They are ugly, but the job they perform is not particularly simple or
> pleasant. There are no real alternatives, and hey, m4 is fun!
>
I didn't complain about m4 ;)
There are alternatives like Boost's jam. It tries to address existing
problems with makefiles and autoconf.
| |
| Måns Rullgård 2005-06-08, 8:58 am |
| phil-news-nospam@ipal.net writes:
> |>> It also builds the Makefile so that make is to be run in a directory
> |>> containing only the Makefile; it references the source by longer paths
> |>> to the directory where the source is extracted, never writing anything
> |>> there (so it can compile straight from a read/only mount, for
> |>> example).
> |>
> |> That's worth a modicum of toil to do :->
> |
> | automake generated makefiles support building in a separate directory
> | with no additional work.
>
> No additional work relative to what?
Relative to using automake recursively.
> There's no work needed to create a config file for automake?
Often less than writing a makefile from scratch. A simple Makefile.am
need no not be more than this:
bin_PROGRAMS = foo
foo_SOURCES = foo.c bar.c
You also need an autoconf script, but that can easily be copied from
somewhere.
--
Måns Rullgård
mru@inprovide.com
| |
| Måns Rullgård 2005-06-08, 8:58 am |
| Lawrence D¹Oliveiro <ldo@g-central.gen.new_zealand> writes:
> In article <yw1x3bruiovx.fsf@ford.inprovide.com>,
> Måns Rullgård <mru@inprovide.com> wrote:
>
>
> Except with systems running non-ANSI C compilers that won't accept
> function prototypes, for example.
Are there any of those still around? The compilers on all machines I
have access to accept at least C89.
--
Måns Rullgård
mru@inprovide.com
| |
| Måns Rullgård 2005-06-08, 8:58 am |
| Zeljko Vrba <mo.dor@fly.srk.fer.hr> writes:
> On 2005-06-07, Roger Leigh <${rleigh}@invalid.whinlatter.ukfsn.org.invalid> wrote:
> I don't have available the environment now.. It was a year ago at my former
> work place. Now I just don't want to bother.
>
> And I also remember autoconf generated configure breaking on Solaris sh
> (not bash!) a few years ago..
Maybe someone used bash constructs in configure.ac. There's not much
autoconf can do about that.
> Please don't ask for examples, and probably you're going to say again it
> was too old version.
A complaint is only valid if the problem exists with the latest
version.
> No. But how do you comment on not being able to guess about -D_ALL_SOURCE?
AFAIK, that's not part of any standard, so how could it possibly be
guessed? The scripts have lists of required flags for many platforms,
and apparently yours wasnt on the list at that time.
> There are alternatives like Boost's jam. It tries to address existing
> problems with makefiles and autoconf.
I looked at it, and I didn't like it. It may work well for the common
simple cases, but if you want to do something unusual it gets tricky.
The elegancy of make is in the generality. You just describe the
dependencies between the files, and how to create them. Jam knows
about programs and libraries, and thus looses in generality. Make is
the Unix way of doing things.
--
Måns Rullgård
mru@inprovide.com
| |
| Peter T. Breuer 2005-06-08, 8:58 am |
| In comp.os.linux.development.system M?ns Rullg?rd <mru@inprovide.com> wrote:
[color=darkred]
> Are there any of those still around? The compilers on all machines I
> have access to accept at least C89.
One solves that with the P macro, and
int foo(P(types));
or other such trickery.
But then if it isn't ansi, I don't care. Standards are there to help
me.
Peter
| |
| Zeljko Vrba 2005-06-08, 4:00 pm |
| On 2005-06-08, Måns Rullgård <mru@inprovide.com> wrote:
>
> I looked at it, and I didn't like it. It may work well for the common
>
To be honest, neither did I. And then there is perl's metaconfig which
generates interactive Configure script (with capital C).
But now that there's X/Open and POSIX, why do we need configure, etc? (an
idealists point of view :)) There should be _SC_ defines, runtime sysconf..
>
> The elegancy of make is in the generality. You just describe the
>
But then you have burden of maintaining dependencies.. Which can be quite
hard in a large project. Then you call compiler for assitance (-M, -MM),
then you try to .include the generated dependencies or do .if and hit
differences between GNU make, BSD make and other make implementations out
there.. Then someone says 'install gmake' then I respond 'my security
policy forbids me to do so' then I have to find another machine with exactly
the same setup and compile there... then compiler itself might require
patches not present on the target machine (which happens on e.g. AIX!), then..
it's a mess..
I've looked at Odin, jam, cook (tool written by the author of 'recursive make
considered harmful').. they all try to solve some kind of make's problem,
inventing a new language and set of internal working rules to learn.. it's
quite a mess :(
| |
| Roger Leigh 2005-06-08, 4:00 pm |
| On 2005-06-08, Zeljko Vrba <mo.dor@fly.srk.fer.hr> wrote:
> On 2005-06-07, Roger Leigh <${rleigh}@invalid.whinlatter.ukfsn.org.invalid> wrote:
> No. But how do you comment on not being able to guess about -D_ALL_SOURCE?
That's not a valid POSIX or SUSv3 feature test macro. If Interix is
SUS-compliant, it shouldn't require wacky macros like that.
_POSIX_C_SOURCE or _XOPEN_SOURCE should be used instead.
This is probably a bug in the code in question, rather than autoconf.
Regards,
Roger
--
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
| |
| Måns Rullgård 2005-06-08, 4:00 pm |
| Zeljko Vrba <mo.dor@fly.srk.fer.hr> writes:
> But then you have burden of maintaining dependencies.. Which can be
> quite hard in a large project. Then you call compiler for assitance
> (-M, -MM), then you try to .include the generated dependencies or do
> .if and hit differences between GNU make, BSD make and other make
Figuring out the dependencies is a problem for any build system.
--
Måns Rullgård
mru@inprovide.com
| |
| Julián Albo 2005-06-08, 4:00 pm |
| Lawrence D¹Oliveiro wrote:
> Except with systems running non-ANSI C compilers that won't accept
> function prototypes, for example.
I've readed in the documentation of automake and autoconf something about a
de-ansification feature that can be used in that cases. Don't remeber
exactly where it is.
--
Salu2
| |
| Lawrence D¹Oliveiro 2005-06-09, 8:57 am |
| In article <42a702f3_1@x-privat.org>, Julián Albo <JULIANALBO@terra.es>
wrote:
>Lawrence D1Oliveiro wrote:
>
>
>I've readed in the documentation of automake and autoconf something about a
>de-ansification feature that can be used in that cases.
That's an example of the kind of feature that shouldn't be necessary in
this day and age. Any compiler that requires it should be quickly and
quietly put out of its misery.
| |
| Lawrence D¹Oliveiro 2005-06-09, 8:57 am |
| In article <yw1xu0k9t4ic.fsf@ford.inprovide.com>,
Måns Rullgård <mru@inprovide.com> wrote:
>Figuring out the dependencies is a problem for any build system.
There have been solutions to this. For instance, Modula-2 and Ada have
very explicit language constructs (enforced by the compiler) for
expressing dependencies between modules. Automating build order for such
languages is a piece of cake.
| |
| Måns Rullgård 2005-06-09, 8:57 am |
| Lawrence D¹Oliveiro <ldo@g-central.gen.new_zealand> writes:
> In article <yw1xu0k9t4ic.fsf@ford.inprovide.com>,
> Måns Rullgård <mru@inprovide.com> wrote:
>
>
> There have been solutions to this. For instance, Modula-2 and Ada have
> very explicit language constructs (enforced by the compiler) for
> expressing dependencies between modules. Automating build order for such
> languages is a piece of cake.
You can't be seriously suggesting that we all drop C, and start using
Modula-2 or Ada.
Another example is Java. As usual, it tries to be helpful, and
automatically compile any dependencies. Also as usual, it gets it all
wrong. I had a problem once involving two Java classes with some
strange interdependence that caused the build to always fail. I got
around it by creating a dummy replacement for one of them while
compiling the other, then restoring and compiling the real version.
--
Måns Rullgård
mru@inprovide.com
| |
| Norman Black 2005-06-09, 3:58 pm |
|
"Måns Rullgård" <mru@inprovide.com> wrote in message
news:yw1xvf4nrjcz.fsf@ford.inprovide.com...
> Lawrence D¹Oliveiro <ldo@g-central.gen.new_zealand> writes:
>
>
> You can't be seriously suggesting that we all drop C, and start using
> Modula-2 or Ada.
I do not think he proposed that you switch. He simply pointed out that C
have never supported compilation units and many other languages do.
Compilation units have advantages. Never any problem with global symbol
naming conflicts. Never any problem with building. Yes, I am a Modula-2
user. In fact I develop the compiler. I have also developed Ada and Borland
Pascal compilers. Building (compiling, linking) a program in any of these
languages is a simple matter of giving the "build" command and the main
program file. Everything else gets dragged in automatically. No make file
exists. The "make" is determined on the fly at the point the "build" command
is given.
Norman Black
Saperion Inc.
| |
| Måns Rullgård 2005-06-09, 3:58 pm |
| "Norman Black" <nospam@nospam.com> writes:
> "Måns Rullgård" <mru@inprovide.com> wrote in message
> news:yw1xvf4nrjcz.fsf@ford.inprovide.com...
>
> I do not think he proposed that you switch. He simply pointed out
> that C have never supported compilation units and many other
> languages do. Compilation units have advantages. Never any problem
> with global symbol naming conflicts. Never any problem with
> building. Yes, I am a Modula-2 user. In fact I develop the
> compiler. I have also developed Ada and Borland Pascal
> compilers. Building (compiling, linking) a program in any of these
> languages is a simple matter of giving the "build" command and the
> main program file. Everything else gets dragged in automatically. No
> make file exists. The "make" is determined on the fly at the point
> the "build" command is given.
It's interesting to note that languages with all these supposedly nice
features hardly ever get used in real programs.
--
Måns Rullgård
mru@inprovide.com
| |
| Norman Black 2005-06-10, 4:00 pm |
|
"Måns Rullgård" <mru@inprovide.com> wrote in message
news:yw1xu0k7o75g.fsf@ford.inprovide.com...
> "Norman Black" <nospam@nospam.com> writes:
>
>
> It's interesting to note that languages with all these supposedly nice
> features hardly ever get used in real programs.
>
History is why. There was a time, when the transition from assembly to high
level languages that the "word" was that C was closer to the processor and
therefore generated better code. This is of course crap but that is what
middle management believed. In reality at that time the best compilers were
more typically C and also since C is not a type checked language an assembly
programmer will feel right at home. Then the object oriented craze hit and C
had an obvious extension in C++. M2 did not have OO extensions for ages. It
is all about market base, and nothing about the language. The other
languages never got enough base to sustain.
Not that important things are not used. Take Modula-2 for example.
Everything nuclear reactor in the US has an M2 program in operation. The
fault tree analysis software in written in M2. A wing of the white house and
the US Marines nuclear weapon storage depots were/are protected by security
software written in Borland Pascal.
Norman
Saperion Inc
|
|
|
|
|