linking c++ code with c library

[Eric Sosman]

Linking must surely be off-topic there too.

"For the C++ aspects," meaning (for example) the mechanics
of calling a C function from C++ code. The fact that you've
got a linker and know how to use it doesn't imply that you can
use a COBOL library from a SNOBOL program.

[...] Anyway the OP didn't even mention an OS,
and may not have wanted a answer for one compiler on one os using one
linker and on a single platform, but may have wanted a broader view.

And he was given it: "Whatever they are, they're not part
of the C language, but (perhaps) of the platforms where C is
implemented." Would a dissertation on the interactions between
`-Bstatic' and `-KPIC' have been "broader?"

On usenet, .c and .c++ groups sound like the best bet for coming across
someone who's already tackled the problem.

Dynamic and static linking are specific to C++ and C?

 

[Nobody]

That question is better addressed in comp.lang.c++.

<OT>
Yes, but the library's header file needs to surround any C function
declarations with extern "C" { ... }

Or, if it doesn't, you need to use e.g.:

extern "C" {
#include <header.h>
}

 

[Frank]

     comp.lang.c++ for the C++ aspects, surely.  And for the
system-specific linker machinery, comp.unix.programmer or
comp.os.ms-windows.something or comp.unix.aix or whatever.

It's more like comp.os.ms-windows.win32.programmer. Keith knows it.

 

[lovecreatesbeauty]

Please understand that this group is here to discuss

(1) The prototype of main is int main(void)
(2) i=i++ is not correct
(3) Answer any homework your teacher may give you so
     that no effort is done by you.

This group is NOT here to discuss:

(1) Anything interesting, related to software development and C
    development in particular.
(2) Any real world discussion like about dynamic linking,
     debuggers, etc.
(3) Any improvements to C as a language. You should use C++
     since that's C future.

you can even discuss porn here, no one can/will stop/s you.

 

[Frank]

Linking must surely be off-topic there too.

C++ provides built-in features, particularly
    extern "C"
for combining C and C++ code.  C does not.  I believe I mentioned
that in my initial response.

So yes, questions regarding extern "C" would surely be topical in
comp.lang.c++ -- assuming you've already tried and failed to find
the answers in the C++ FAQ.

As for static vs. dynamic linking, I don't believe C++ provides any
mechanism that distinguishes between the two.  So it's not a language
issue, any more than vi vs. emacs is a language issue.  You might as
well ask in comp.lang.fortran (no, that's not a serious suggestion).

[...]

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <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"

yes it is.

with the contrast to fortran and perl, we have C without objects in
the "object-oriented" sense.

I think this has consequences for linkage.

 

[BartC]

BartC wrote:

Out of interest, how do you think dynamic linkage is managed under
windows, without a linker?

MS Windows has a dynamic link specification and built-in loaders for the
same.

But that doesn't help in converting your C or C++ source code to a dynamic
library or to a static executable.

 

[Nick Keighley]

MS Windows has a dynamic link specification and built-in loaders for the
same.

But that doesn't help in converting your C or C++ source code to a dynamic
library or to a static executable.

who said it did?

 

[jacob navia]

Why don't you read what nick wrote, instead of leaping in with both feet?


Does it mention static or dynamic linking there?

It mentions explicitely linking as phase 8 of program translation.
This means that linking is part of the language and that discussions
about linking both dynamic and static are ON TOPIC here, contrary to what
Mr Keighly wrote:

"dynamic and static linking are not mentioned in the C standard"

Linking *is* mentioned, so both are ON TOPIC.

 

[jacob navia]

Please understand that this group is here to
1) be a channel for Jacob's complaints that the regulars hate him
2) be a channel for jacob's sarcasm
3) be a channel for Jacob to discuss his pet topics,

This group is NOT here to discuss
a) anything Jacob doesn't like
b) anyone's opinion except jacob's
c) the c programming language.

Apparently.

McIntyre has never written anything technical here
and his contributions are just polemic against other
people. He only appears here to distribute insults or
ironic remarks.

Best forgotten!

 

[jacob navia]

All of this, by hte way, shows why this isnt topical here. Almost nobody
who has contributed to this thread knows enough to be useful.

Speak for yourself...

 

[James Kuyper]

Speak for yourself...

He is speaking for himself - he's describing HIS assessment of the
qualifications of the other posters on this thread. Note, also, that the
"almost" allows for the possibility of a few exceptions. Personally, I
think his claim is overstated - I suspect that several of the people
here do know enough to be useful, but prefer to discuss it in a
different forum, where it would be more topical.

However, while there's been a lot of discussion about the topicality of
this thread, no one has actually answered the original question, so his
assessment seems fully justified with respect to those who don't care
about topicality - they have no excuse that I'm aware of for not
answering, so it's reasonable to presume that they may not know the answer.

So far, the closest thing we've seen to an actual answer was a message
from Keith Thompson, citing a link to a C++ FAQ that explains what needs
to be done at the source code level. However, as he himself
acknowledged, this isn't a complete answer, because it says nothing
about what needs to be done to link the program together once the source
code is written. The answer to that question is highly
implementation-dependent.

 

[Flash Gordon]

It mentions explicitely linking as phase 8 of program translation.

Yes, and to the extent it is specified by the standard it is on topic.

This means that linking is part of the language and that discussions
about linking both dynamic and static are ON TOPIC here, contrary to what
Mr Keighly wrote:

"dynamic and static linking are not mentioned in the C standard"

Linking *is* mentioned, so both are ON TOPIC.

Dynamic linking, as it is often described, i.e. calling a function from
within your application which causes a library specified in some manner
by the program, e.g. the dlopen function, is nothing to do with either
the C standard or standard C but everything to do with the specific OSs
(and classes of OS) that provide it in different ways. So dynamic
linking as it is often understood is off topic.

Other people use the term dynamic linking in a different way which
includes the program loader seeing that the image requires certain
specific libraries and loads them at that point. To some extent such
dynamic linking is topical, but only to a very limited degree since the
standard does not say much about linking.

Static linking is also to a limited degree topical.

None of the differences between static and dynamic linking are topical,
since to the degree the C standard defines linking it is invisible to
the program.

I've read a lot about certain specific linkers (both dynamic and static)
and almost all of it has nothing to do with C.

 

[Richard Bos]

It mentions explicitely linking as phase 8 of program translation.
This means that linking is part of the language and that discussions
about linking both dynamic and static are ON TOPIC here, contrary to what
Mr Keighly wrote:

"dynamic and static linking are not mentioned in the C standard"

Linking *is* mentioned, so both are ON TOPIC.

Deleting a file is mentioned in the Standard. Does this mean that the
difference between moving a file to the MS Windows trash can and really
deleting it is on-topic?

The arguments to main() are mentioned in the Standard. Does that mean
that ways to create those arguments on a pre-OSX Macintosh are on-topic?

The source files in #include "file" directives are searched for. Does
this mean that file system organisation is on-topic here?

Four times no.

The Standard mentions linking, but it says nothing about _how_ that
linking must be done. All it says is that translated TUs and libraries
may or must be linked. It does not mention dynamic or static linking,
the difference between those two, or how or even whether they are
available on various systems.

Richard

 

[jacob navia]

Deleting a file is mentioned in the Standard. Does this mean that the
difference between moving a file to the MS Windows trash can and really
deleting it is on-topic?

Yes, as any real world problem related to the language.

The arguments to main() are mentioned in the Standard. Does that mean
that ways to create those arguments on a pre-OSX Macintosh are on-topic?

Yes, since they are related to the language. It is here where people
that know this type of answer could give their advise.

The source files in #include "file" directives are searched for. Does
this mean that file system organisation is on-topic here?

As far as it is related to programming in C, yes.

Four times no.

Four times yes.

The Standard mentions linking, but it says nothing about _how_ that
linking must be done. All it says is that translated TUs and libraries
may or must be linked. It does not mention dynamic or static linking,
the difference between those two, or how or even whether they are
available on various systems.

Richard

Obviously the standard does NOT mention anything like that. That is why
if you want answers to specific questions you can ask here.

Contrary to the "regulars" group, I think that this group is here to
discuss about real problems people find in their usage of the language.

 

[Keith Thompson]

Richard Bos wrote: [...]

Deleting a file is mentioned in the Standard. Does this mean that the
difference between moving a file to the MS Windows trash can and really
deleting it is on-topic?

Yes, as any real world problem related to the language.

[...]

How is that related to the language?

 

[Frank]

C++ provides built-in features, particularly
    extern "C"
for combining C and C++ code.  C does not.  I believe I mentioned
that in my initial response.

So yes, questions regarding extern "C" would surely be topical in
comp.lang.c++ -- assuming you've already tried and failed to find
the answers in the C++ FAQ.

As for static vs. dynamic linking, I don't believe C++ provides any
mechanism that distinguishes between the two.  So it's not a language
issue, any more than vi vs. emacs is a language issue.  You might as
well ask in comp.lang.fortran (no, that's not a serious suggestion).

[...]

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <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"

yes it is.

with the contrast to fortran and perl, we have C without objects in
the "object-oriented" sense.

I think this has consequences for linkage.- Hide quoted text -

- Show quoted text -

I asked in clf and I appear to be unequivocally wrong. Cheers,

 

[Nick Keighley]

Yes, as any real world problem related to the language.

there's a bug in a build system I'm using to build a C program.
It crashes in a python program whilst parsing a configuration file.
Should I post the error here? It's a real world problem as far as I'm
concerned and it is building a C program

 

[lovecreatesbeauty]

Yes, as any real world problem related to the language.


Yes, since they are related to the language. It is here where people
that know this type of answer could give their advise.


As far as it is related to programming in C, yes.


Four times yes.


Obviously the standard does NOT mention anything like that. That is why
if you want answers to specific questions you can ask here.

Contrary to the "regulars" group, I think that this group is here to
discuss about real problems people find in their usage of the language.

I want to have linux source code tree on my linux box hosted in VMWare
virtial pc. I download and build the kernel version 2.6.28 on debian
5.0 with built kernel version 2.6.26. It takes a whole night on my
aged pc with 128M RAM and a 700MHz AMD CPU which I bought nearly 6
years ago. I go to bed after issue the command: make && su -c 'make
install'. The process finishes at the next morning, and it is
successful.

The bad thing is the new kernel can not boot the system*. I bear with
the noise from the pc fan for nothing and waste the whole night. The
debian 5.0 and the linux kernal are both written in C. Do you consider
this a problem topical here and help me out of the trouble?

*
http://seuofg.bay.livefilestore.com...ux-2.6.26.1_linux-2.6.28.5_no modules.dep.bmp

 

[Beej Jorgensen]

The bad thing is the new kernel can not boot the system*. I bear with
the noise from the pc fan for nothing and waste the whole night. The
debian 5.0 and the linux kernal are both written in C. Do you consider
this a problem topical here and help me out of the trouble?

Since this doesn't appear to be a C problem, you're more likely to get a
good response on a Linux newsgroup.

But since you're here, did you "make modules_install"? And you're using
initrd--did you go through the steps to set the image up correctly?
Check the Documentation directory in the Linux kernel source tree for
more info.

-Beej

 

[lovecreatesbeauty]

Since this doesn't appear to be a C problem, you're more likely to get a
good response on a Linux newsgroup.

Sorry to posted it here.

But since you're here, did you "make modules_install"? And you're using
initrd--did you go through the steps to set the image up correctly?
Check the Documentation directory in the Linux kernel source tree for
more info.

I did the following and edited the grub config*.
$ su -c 'make modules_install'
$ su -c 'update-initramfs -c -k 2.6.26.3'

* http://www.grex.org/~jhl/kernelbasis.txt
(I just made kernel update successfully twice. This was one. Another
success was to update kernel 2.4 to 2.6 on debian 3.

The new kernel doesn't boot at the most of time. I didn't include all
required module, and failed to boot it? But I just used make defconfig
and plus CONFIG_PCNET32 for one of the two successful cases above.)