libtool

[Neil Morris]

Dear All

Is it possible to code in c using libtool an executable that list the
symbols in shared/static libraries? Could someone show an example?

thanks in advance

[Keith Thompson]

Neil Morris <ne**********@virgin.netwrites:

Is it possible to code in c using libtool an executable that list the
symbols in shared/static libraries? Could someone show an example?

There's no portable C solution. If you're using a Unix-like system,
try asking in comp.unix.programmer; otherwise, try a newsgroup that
deals with your system.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Antoninus Twink]

On 15 Sep 2008 at 23:26, Keith Thompson wrote:

Neil Morris <ne**********@virgin.netwrites:

>Is it possible to code in c using libtool an executable that list the
symbols in shared/static libraries? Could someone show an example?

There's no portable C solution.

Of course, this is complete nonsense.

All that is required is to parse a binary file, and this can be done in
100% portable C.

The OP could check out the source code to nm in the GNU binutils, for
example: http://www.gnu.org/software/binutils/

[James Kuyper]

Antoninus Twink wrote:

On 15 Sep 2008 at 23:26, Keith Thompson wrote:

>Neil Morris <ne**********@virgin.netwrites:

>>Is it possible to code in c using libtool an executable that list the
symbols in shared/static libraries? Could someone show an example?

There's no portable C solution.

Of course, this is complete nonsense.

All that is required is to parse a binary file, and this can be done in
100% portable C.

The same code can be used to parse shared/static libraries on all
implementations of C? How was a single uniform library file format
established? When? By whom? Who's responsible for executing anyone who
might otherwise dare to define a new, incompatible library file format?
How did they get rid of all of the legacy systems using different file
formats?

[Alcari The Mad]

James Kuyper wrote:

Antoninus Twink wrote:

>On 15 Sep 2008 at 23:26, Keith Thompson wrote:

>>Neil Morris <ne**********@virgin.netwrites:
Is it possible to code in c using libtool an executable that list the
symbols in shared/static libraries? Could someone show an example?
There's no portable C solution.

Of course, this is complete nonsense.

All that is required is to parse a binary file, and this can be done in
100% portable C.

The same code can be used to parse shared/static libraries on all
implementations of C? How was a single uniform library file format
established? When? By whom? Who's responsible for executing anyone who
might otherwise dare to define a new, incompatible library file format?
How did they get rid of all of the legacy systems using different file
formats?

He didn't say it will parse any binary file, just that the parser is
portable.

--AlcariTheMad

[James Kuyper]

Alcari The Mad wrote:

James Kuyper wrote:

>Antoninus Twink wrote:

>>On 15 Sep 2008 at 23:26, Keith Thompson wrote:
Neil Morris <ne**********@virgin.netwrites:
Is it possible to code in c using libtool an executable that list the
symbols in shared/static libraries? Could someone show an example?
There's no portable C solution.
Of course, this is complete nonsense.

All that is required is to parse a binary file, and this can be done in
100% portable C.

The same code can be used to parse shared/static libraries on all
implementations of C? How was a single uniform library file format
established? When? By whom? Who's responsible for executing anyone who
might otherwise dare to define a new, incompatible library file format?
How did they get rid of all of the legacy systems using different file
formats?

He didn't say it will parse any binary file,

I didn't criticize his suggestion on those grounds. I criticized his
suggestion the ground that it will not correctly parse all library file
formats. That's too large a set of file formats to be correctly parsed
by a single program of a size small enough to be portable to all
implementations of C, but it's a much smaller set than the set of all
binary files.

... just that the parser is
portable.

He said "that is complete nonsense" in response to the assertion "there
is no portable C solution", and presented the idea of this parser as if
it was proof that the assertion was false. It would constitute such
proof only if it were a portable solution. It may be portable code, and
it may be the correct solution to the problem on many platforms, but
it's only a portable solution if it correctly solves the problem on all
of the systems it can be ported to. It can't be a portable solution,
because the problem to be solved is different on different systems.

[viza]

On Tue, 16 Sep 2008 00:52:44 +0000, James Kuyper wrote:

Alcari The Mad wrote:

>James Kuyper wrote:

>>Antoninus Twink wrote:
On 15 Sep 2008 at 23:26, Keith Thompson wrote:
Neil Morris <ne**********@virgin.netwrites:
>Is it possible to code in c using libtool an executable that list
>the symbols in shared/static libraries? Could someone show an
>example?
There's no portable C solution.
Of course, this is complete nonsense.

All that is required is to parse a binary file, and this can be done
in 100% portable C.
The same code can be used to parse shared/static libraries on all
implementations of C? How was a single uniform library file format
established? When? By whom? Who's responsible for executing anyone who
might otherwise dare to define a new, incompatible library file
format? How did they get rid of all of the legacy systems using
different file formats?

He didn't say it will parse any binary file,

I didn't criticize his suggestion on those grounds. I criticized his
suggestion the ground that it will not correctly parse all library file
formats. That's too large a set of file formats to be correctly parsed
by a single program of a size small enough to be portable to all
implementations of C, but it's a much smaller set than the set of all
binary files.

What complete nonsense! If I write {int foo[1000000]; then the code
can't be run on a system without enough memory for one million ints, but
the hardware limitation doesn't make the code not portable C, otherwise
you could just as easily say that {int bar[2]; is not portable C because
it won't run on a system without enough memory for that.

>... just that the parser is portable.

He said "that is complete nonsense" in response to the assertion "there
is no portable C solution"

correctly.

It may be portable code, and it may be the correct solution to the
problem on many platforms, but it's only a portable solution if it
correctly solves the problem on all of the systems it can be ported to.

Look up "portable". It doesn't mean "which runs on every programable
device ever built".

It can't be a portable solution,
because the problem to be solved is different on different systems.

A conceivable portable program could handle every format ever used, which
would make determining which format to use is just a matter of local
configuration or a run-time option.

[James Kuyper]

viza wrote:

On Tue, 16 Sep 2008 00:52:44 +0000, James Kuyper wrote:

>Alcari The Mad wrote:

>>James Kuyper wrote:
Antoninus Twink wrote:
On 15 Sep 2008 at 23:26, Keith Thompson wrote:
>Neil Morris <ne**********@virgin.netwrites:
>>Is it possible to code in c using libtool an executable that list
>>the symbols in shared/static libraries? Could someone show an
>>example?
>There's no portable C solution.
Of course, this is complete nonsense.
>
All that is required is to parse a binary file, and this can be done
in 100% portable C.
The same code can be used to parse shared/static libraries on all
implementations of C? How was a single uniform library file format
established? When? By whom? Who's responsible for executing anyone who
might otherwise dare to define a new, incompatible library file
format? How did they get rid of all of the legacy systems using
different file formats?
He didn't say it will parse any binary file,

I didn't criticize his suggestion on those grounds. I criticized his
suggestion the ground that it will not correctly parse all library file
formats. That's too large a set of file formats to be correctly parsed
by a single program of a size small enough to be portable to all
implementations of C, but it's a much smaller set than the set of all
binary files.

What complete nonsense! If I write {int foo[1000000]; then the code
can't be run on a system without enough memory for one million ints, but
the hardware limitation doesn't make the code not portable C, otherwise
you could just as easily say that {int bar[2]; is not portable C because
it won't run on a system without enough memory for that.

The key word here isn't "portable", it's "solution". You may wish to
adhere to an abstract definition of portability that allows you to say a
program is portable even if there are machines with fully conforming
implementations of C to which it cannot actually be ported to. However,
how can you possibly justify calling it a solution for those machines?

>>... just that the parser is portable.

He said "that is complete nonsense" in response to the assertion "there
is no portable C solution"

correctly.

>It may be portable code, and it may be the correct solution to the
problem on many platforms, but it's only a portable solution if it
correctly solves the problem on all of the systems it can be ported to.

Look up "portable". It doesn't mean "which runs on every programable
device ever built".

"portable" has no fixed meaning; people use it with different meanings
in different contexts. In this newsgroup, in the absence of a statement
to the contrary, it generally means portable to all conforming
implementations of C.

Which version of the standard conformance is to be measured against is
unspecified, different people assume different defaults: some say C90,
some say C99, some say it must be portable to both. I'm sure there's
people who don't consider code portable unless it will also compile
under a wide variety of pre-standard compilers.

There are also people who consider code that won't compile on any system
that doesn't have a version of Windows installed to be portable. There
are limits to my willingness to accept personalized definitions of the
word 'portable'; that case exceeds my limits; you may feel otherwise.

Since it didn't matter to my statement which standard was relevant, I
followed the practice of those I was responding to, by leaving it
unspecified.

>It can't be a portable solution,
because the problem to be solved is different on different systems.

A conceivable portable program could handle every format ever used, which
would make determining which format to use is just a matter of local
configuration or a run-time option.

Yes, but such a program would not actually solve the problem on any of
the machine that it could not actually be ported to, regardless of
whether it meets your abstract definition of "portable".

[CBFalconer]

James Kuyper wrote:

Antoninus Twink wrote:

.... snip ...

>

>Of course, this is complete nonsense.

All that is required is to parse a binary file, and this can be
done in 100% portable C.

The same code can be used to parse shared/static libraries on
all implementations of C? How was a single uniform library file
format established? When? By whom? Who's responsible for
executing anyone who might otherwise dare to define a new,
incompatible library file format? How did they get rid of all of
the legacy systems using different file formats?

--
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT F :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | jgs (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
================================================== ============

fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchinson

[Antoninus Twink]

On 16 Sep 2008 at 0:37, James Kuyper wrote:

Antoninus Twink wrote:

>On 15 Sep 2008 at 23:26, Keith Thompson wrote:

>>Neil Morris <ne**********@virgin.netwrites:
Is it possible to code in c using libtool an executable that list the
symbols in shared/static libraries? Could someone show an example?
There's no portable C solution.

Of course, this is complete nonsense.

All that is required is to parse a binary file, and this can be done in
100% portable C.

The same code can be used to parse shared/static libraries on all
implementations of C? How was a single uniform library file format
established? When? By whom? Who's responsible for executing anyone who
might otherwise dare to define a new, incompatible library file format?
How did they get rid of all of the legacy systems using different file
formats?

Your points are not relevant.

Let's suppose, for the sake of argument, that the OP wants to list the
symbols in an ELF library on x86 Linux. It is possible to write a 100%
portable program that will do that and run on any platform. Even if the
library itself is useless on that platform, the only pertinent fact is
that the layout of the library, considered purely as a sequence of bytes
in a file, is well-defined.

So you pedants can say: "just fopen() the library, use fread() and
consult the specification for the library format(s) that you want to
read (don't forget to #include <stdio.h>, don't cast the return value of
malloc, and remember that main returns an int)." The words "list the
symbols in an ELF library on x86 Linux" can be replaced by "parse a
black-box binary file". (Of course, there may well be better solutions
for a given library format on a given platform, but there *is* a
"standard" way to read binary files on any plaform, contrary to Keith's
claim.)

But instead you go on and on with this nonsense interpreting the OP as
wanted to write a program to work miracles and simultaneously parse
every object file format ever invented and every object file format
still to come. Do you think this is possible on any platform even with
platform-specific code? Is platform-specific code able to walk on water?
And do you think the OP is an idiot?

[Kenny McCormack]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote an excellent post, that
hits all the right notes, in just the right sequence, that summarizes
best as:
....

>Your points are not relevant.

Let's suppose, for the sake of argument, that the OP wants to list the
symbols in an ELF library on x86 Linux. It is possible to write a 100%
portable program that will do that and run on any platform. Even if the
library itself is useless on that platform, the only pertinent fact is
that the layout of the library, considered purely as a sequence of bytes
in a file, is well-defined.

So you pedants can say: "just fopen() the library, use fread() and
consult the specification for the library format(s) that you want to
read (don't forget to #include <stdio.h>, don't cast the return value of
malloc, and remember that main returns an int)."

Yes. Those are the salient points, after all.
Indeed, indeed. Remember always: DO NOT CAST THE RETURN VALUE OF MALLOC().

And finally, observe that this thread illustrates clearly how the regs
can always come up with a way to intentionally misinterpret the newbie
posts in a way that gives them license to be jerks. What small lives
they lead...

[Mark McIntyre]

viza wrote:

If I write {int foo[1000000]; then the code
can't be run on a system without enough memory for one million ints, but
the hardware limitation doesn't make the code not portable C,

it does, actually. See section 5.2.4 of the Standard.

otherwise

you could just as easily say that {int bar[2]; is not portable C because
it won't run on a system without enough memory for that.

However the Standard requires a conforming C implementation to support
at least certain size objects (again, see 5.2.4). So any implementation
which didn't support a two-int array wouldn't be legal C.

Look up "portable". It doesn't mean "which runs on every programable
device ever built".

In the context of the C Language, it generally means "compiles
successfully and works the same on any conforming implementation".

I agree though that failing to do anything useful is a form of working,
so in that rather limited sense, the Other Troll's answer might be
considered 'portable'.

A conceivable portable program could handle every format ever used,

*every*?
List them. All of them. Including the one being developed right now in
secret by the guys who are about to release an amazing new
super-efficient format on the world. Including the ones developed
privately by companies and never released to the public.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[jameskuyper]

CBFalconer wrote:

James Kuyper wrote:

Antoninus Twink wrote:

... snip ...

Of course, this is complete nonsense.

All that is required is to parse a binary file, and this can be
done in 100% portable C.

The same code can be used to parse shared/static libraries on
all implementations of C? How was a single uniform library file
format established? When? By whom? Who's responsible for
executing anyone who might otherwise dare to define a new,
incompatible library file format? How did they get rid of all of
the legacy systems using different file formats?

--
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT F :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | jgs (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

I'm sorry - when I use Thunderbird as my newsreader on my home
computer, I can filter out his nonsense. However, at work I can only
use Google groups, and then I occasionally see his messages while
scrolling through others. He's surely an expert at saying ridiculous
things that make me want to correct him, but I've got to learn to
resist that temptation.

[Richard]

ja*********@verizon.net writes:

CBFalconer wrote:

>James Kuyper wrote:

Antoninus Twink wrote:

... snip ...

>
Of course, this is complete nonsense.

All that is required is to parse a binary file, and this can be
done in 100% portable C.

The same code can be used to parse shared/static libraries on
all implementations of C? How was a single uniform library file
format established? When? By whom? Who's responsible for
executing anyone who might otherwise dare to define a new,
incompatible library file format? How did they get rid of all of
the legacy systems using different file formats?

--
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT F :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | jgs (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

I'm sorry - when I use Thunderbird as my newsreader on my home
computer, I can filter out his nonsense. However, at work I can only
use Google groups, and then I occasionally see his messages while
scrolling through others. He's surely an expert at saying ridiculous
things that make me want to correct him, but I've got to learn to
resist that temptation.

Best just to killfile Falconer. He is not the management and 9 times out
of 10 he is wrong on his topicality claims.

[jameskuyper]

Richard wrote:

ja*********@verizon.net writes:

....

Best just to killfile Falconer. He is not the management and 9 times out
of 10 he is wrong on his topicality claims.

He often makes mistakes, many of them apparently due to failing to
read messages sufficiently thoroughly. I've sometimes wondered whether
he could possibly be a fake sent in by those on the wrong side of the
topicality debates to make our side of those debates look bad. Still,
he is right about Twinkletoes. I'll killfile you long before I
killfile him.

[Richard]

ja*********@verizon.net writes:

Richard wrote:

>ja*********@verizon.net writes:

...

>Best just to killfile Falconer. He is not the management and 9 times out
of 10 he is wrong on his topicality claims.

He often makes mistakes, many of them apparently due to failing to
read messages sufficiently thoroughly. I've sometimes wondered whether

The reasons are immaterial.

he could possibly be a fake sent in by those on the wrong side of the
topicality debates to make our side of those debates look bad. Still,

Uh huh. So basically you have zero respect for his contributions if you
think that. So you agree.

he is right about Twinkletoes. I'll killfile you long before I

Who cares about his opinion? FWIW I think he is wrong there too. Twink
posts far more things of interest for C programmers than most
combined. But then I think a great deal of the posters here have their
head where the sun dont shine in their over zealous policing of
"topicality". This group is comp.lang.c. It is here to discuss C
issues. Sometimes there are NOT better groups which are adequately
populated.

killfile him.

Feel free. Personally I think the killfile is the resort of a coward in
most cases. But in Falconers case he is technically incompetent too
frequently to be taken seriously, clearly has about zero real world
experience as his comments about development and maintenance prove and
a bully to new posters to boot. Basically not someone I would like to
work with.

[jameskuyper]

Richard wrote:

ja*********@verizon.net writes:

....

he is right about Twinkletoes. I'll killfile you long before I

Who cares about his opinion?

I don't care about the fact that it's his opinion. I do care about the
fact that he reminded me of advice that I consider to be correct,
regardless of its source. I would even accept the same advice if it
was given to me by the Twinkie himself.

FWIW I think he is wrong there too. Twink
posts far more things of interest for C programmers than most
combined. But then I think a great deal of the posters here have their
head where the sun dont shine in their over zealous policing of
"topicality". This group is comp.lang.c. It is here to discuss C
issues.

I stopped paying attention to him when I realized that most of his
posts consist of undeserved insults to other people. However, before I
stopped paying attention, I noticed that on those rare occasions when
he did make a technical contribution, which was usually off-topic by
reason of answering an implementation-specific question, he would
often provide a demonstration of precisely why it's a bad idea to
discuss such things in this news group. He made unwarranted and
frequently false assumptions about which implementation was relevant
to a given off-topic question. He also frequently gave bad
implementation-specific advice; since most of the people who were
competent to recognize that the advice was bad had him killfiled, the
bad advice often went unchallenged. The key advantage of
implementation-specific newsgroups is that bad advice from one denizen
will often be balanced by good advice from other participants.

... Sometimes there are NOT better groups which are adequately
populated.

As a general rule, if the number of experts on given implementation
who monitor the corresponding implementation-specific newsgroup is
inadequate, the number of experts on that implementation who monitor
this newsgroup is even more inadequate.

Feel free. Personally I think the killfile is the resort of a coward in
most cases.

No, it's just a sophisticated way of doing the same thing you do when
you realize that someone is not worth listening to. Everyone has a
inherent right to speak; but no one has the inherent right to insist
that I listen to what he's saying. Catching people's attention,
holding it, and developing a reputation as someone worth listening to
is a skill and an art, it's not an entitlement.

[Richard Heathfield]

ja*********@verizon.net said:

Richard wrote:

>ja*********@verizon.net writes:

...

>Best just to killfile Falconer. He is not the management and 9 times out
of 10 he is wrong on his topicality claims.

He often makes mistakes, many of them apparently due to failing to
read messages sufficiently thoroughly. I've sometimes wondered whether
he could possibly be a fake sent in by those on the wrong side of the
topicality debates to make our side of those debates look bad.

I have good reason to believe that CBFalconer is not a sock puppet. If he
is one, his controller is playing a very long game indeed.

Still,
he is right about Twinkletoes. I'll killfile you long before I
killfile him.

Beat you to it. Richard Riley lost my attention a long time ago, and shows
no prospect of regaining it, to judge by the bits of his articles that I
see in context-quotes such as the above.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard]

Richard Heathfield <rj*@see.sig.invalidwrites:

ja*********@verizon.net said:

>Richard wrote:

>>ja*********@verizon.net writes:

...

>>Best just to killfile Falconer. He is not the management and 9 times out
of 10 he is wrong on his topicality claims.

He often makes mistakes, many of them apparently due to failing to
read messages sufficiently thoroughly. I've sometimes wondered whether
he could possibly be a fake sent in by those on the wrong side of the
topicality debates to make our side of those debates look bad.

I have good reason to believe that CBFalconer is not a sock puppet. If he
is one, his controller is playing a very long game indeed.

>Still,
he is right about Twinkletoes. I'll killfile you long before I
killfile him.

Beat you to it. Richard Riley lost my attention a long time ago, and shows
no prospect of regaining it, to judge by the bits of his articles that I
see in context-quotes such as the above.

You're an arse Heathfield. You need to get over yourself.

[Kenny McCormack]

In article <ga**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
....

>You're an arse Heathfield. You need to get over yourself.

He wouldn't be nearly as much fun if he did.

[Antoninus Twink]

On 16 Sep 2008 at 17:03, ja*********@verizon.net wrote:

I stopped paying attention to him when I realized that most of his
posts consist of undeserved insults to other people.

Sometimes, frustration does boil over, and "insults" come out. You
should know: only a few hours ago, you wrote of "Chuck":

I've sometimes wondered whether he could possibly be a fake sent in by
those on the wrong side of the topicality debates to make our side of
those debates look bad.

The measured tone only makes the sentiment more damning.

In my defence, I only ever pay people back in kind: the people I have
harsh words for have *all* been guilty of sustained nasty bullying
campaigns in this newsgroup.

However, before I stopped paying attention, I noticed that on those
rare occasions when he did make a technical contribution, which was
usually off-topic by reason of answering an implementation-specific
question, he would often provide a demonstration of precisely why it's
a bad idea to discuss such things in this news group. He made
unwarranted and frequently false assumptions about which
implementation was relevant to a given off-topic question. He also
frequently gave bad implementation-specific advice.

Unlike some of the clc regulars, I'm not an ego-maniac, and I realize
that I sometimes make mistakes. When I do, surely the productive thing
is to correct them on the spot, rather than saying nothing and then
weeks later making vague and unsubstantiated insinuations about my
technical competence?