|
|
Sponsored Content
Top Forums
Shell Programming and Scripting
Makefile Mix for C and C++
Post 302703963 by DGPickett on Thursday 20th of September 2012 04:30:52 PM
09-20-2012
extern "C" - C++ Forum
On all C++ compilers, extern "C" {} turns off mangling so C++ can call C. You use it in the C++ files only, to call C functions that have no C++ versions, i.e., when necessary.
Newer C compilers can mangle names and call C++ functions, if you declare them with extern "C++" in the C files only.
cc -c compiles something.c into (usually) something.o, an unlinked object file. If you want to link to static library somelib.a or prepare it to run-time link to dynamic library somelib.so, a second pass of cc -o something, or an internal second pass if no -c, links (actually using ld) the .o and library stuff together to an exec() friendly executable object file. Static libraries are archves from ar of *.o files, and ld copies the relevant parts of them into the statically linked executable. Dynamic libraries can be made for static ones, perhaps internally linking modules that call each other, and of course geting a new suffix and magic. Dynamic executable files just have stubs to allow a call to ld() at run time to find .so libraries in the original or $LD_LIBRARY_PATH directories, mmap() them into the memory space of the process, and set pointers to the mapped parts. All running copies of 'something' use the same *.so file mapped into the same RAM pages, except for initialized modifiable variables, which are often just initialization constants and a spec for variable space, so non-variable parts can be mapped into read-only pages. Statically linked copies of something *might* all use separate RAM copies of the code, if exec() does not use mmap(), and they roll out on separate parts of swap. Dynamic is especially wise when many programs use the same calls, so they use the same RAM & cache, and not so much swap. For instance, most C programs use libc, so it is linked by default. In dynamic mode, all C programs use the same libc.so mapped in the same RAM pages. If your dynamically linked executable goes to machines with a too different libc.so, they fail. Static linking means that never happens. Dynamic linking is for real men!
You can ensure the right libraries are found with $LD_LIBRARY_PATH, just the same way you might control where 'cc' is found using $PATH.
BTW, set-uid and set-gid executables unset the $LD_LIBRARY_PATH so you need to compile them without moving the .so from run time, and often with a cc option like -R to burn in fixed library paths at compile time. This is why it is so hard to write a set-uid script -- interpreter cannot link. You have to write your own fixed path interpreter wrapper!
On all C++ compilers, extern "C" {} turns off mangling so C++ can call C. You use it in the C++ files only, to call C functions that have no C++ versions, i.e., when necessary.
Newer C compilers can mangle names and call C++ functions, if you declare them with extern "C++" in the C files only.
cc -c compiles something.c into (usually) something.o, an unlinked object file. If you want to link to static library somelib.a or prepare it to run-time link to dynamic library somelib.so, a second pass of cc -o something, or an internal second pass if no -c, links (actually using ld) the .o and library stuff together to an exec() friendly executable object file. Static libraries are archves from ar of *.o files, and ld copies the relevant parts of them into the statically linked executable. Dynamic libraries can be made for static ones, perhaps internally linking modules that call each other, and of course geting a new suffix and magic. Dynamic executable files just have stubs to allow a call to ld() at run time to find .so libraries in the original or $LD_LIBRARY_PATH directories, mmap() them into the memory space of the process, and set pointers to the mapped parts. All running copies of 'something' use the same *.so file mapped into the same RAM pages, except for initialized modifiable variables, which are often just initialization constants and a spec for variable space, so non-variable parts can be mapped into read-only pages. Statically linked copies of something *might* all use separate RAM copies of the code, if exec() does not use mmap(), and they roll out on separate parts of swap. Dynamic is especially wise when many programs use the same calls, so they use the same RAM & cache, and not so much swap. For instance, most C programs use libc, so it is linked by default. In dynamic mode, all C programs use the same libc.so mapped in the same RAM pages. If your dynamically linked executable goes to machines with a too different libc.so, they fail. Static linking means that never happens. Dynamic linking is for real men!
You can ensure the right libraries are found with $LD_LIBRARY_PATH, just the same way you might control where 'cc' is found using $PATH.BTW, set-uid and set-gid executables unset the $LD_LIBRARY_PATH so you need to compile them without moving the .so from run time, and often with a cc option like -R to burn in fixed library paths at compile time. This is why it is so hard to write a set-uid script -- interpreter cannot link. You have to write your own fixed path interpreter wrapper!
|
|
8 More Discussions You Might Find Interesting
1. Shell Programming and Scripting
Hi Guys,
i'm beginner in UNIX commands, need some help on this simple question:
I need to make a shell script to move files to another directory,
the criterias are :
1. the range of 4 last digit of the file name is 0100-0199
2. move all files that processed daily (let's say today is... (2 Replies)
Discussion started by: saltshaker
2 Replies
2. AIX
I have a problem with some partitions.
In one of them I have this two fiber channel.
lsdev -Cc adapter
ent0 Available 03-08 10/100/1000 Base-TX PCI-X Adapter (14106902)
fcs0 Available 04-08 FC Adapter
fcs1 Available 05-08 FC Adapter
ide0 Defined 07-08 ATA/IDE... (0 Replies)
Discussion started by: lo-lp-kl
0 Replies
3. UNIX for Advanced & Expert Users
Hi, I'm trying to run the module load command in a Makefile and i'm getting the following error:
make: module: command not found
Why is this? Is there any way to run this command in a Makefile?
NOTE: command - module load msjava/sunjdk/1.5.0 works fine outside of the Makefile (2 Replies)
Discussion started by: hernandinho
2 Replies
4. Solaris
Hi all
I plan to install Solaris 10U6 on some SPARC server using ZFS as root pool, whereas I would like to keep the current setup done by VxVM:
- 2 internal disks: c0t0d0 and c0t1d0
- bootable root-volume (mirrored, both disks)
- 1 non-mirrored swap slice
- 1 non-mirrored slices for Live... (1 Reply)
Discussion started by: blicki
1 Replies
5. Shell Programming and Scripting
Hello Everybody!
My question is how can I mix for example file_a with file_b in the following method:
After 2 lines of file_a put 2 lines from file_b to file_c.
For example:
file_a:
1
2
3
4
5
6
file_b:
11
22 (7 Replies)
Discussion started by: Levi85
7 Replies
6. Homework & Coursework Questions
Use and complete the template provided. The entire template must be completed. If you don't, your post may be deleted!
1. The problem statement, all variables and given/known data:
Basically, the prompt is make a makefile with various sub makefiles in their respective subdirectories. All code... (1 Reply)
Discussion started by: Tatl
1 Replies
7. Programming
I am trying to come up with a makefile where the target is linked with object files produced by C and C++ sources.
My setup is Ubuntu/gcc:
$ uname -a
Linux srvr1 2.6.24-24-server #1 SMP Fri Sep 18 17:24:10 UTC 2009 i686 GNU/Linux
gcc version 4.2.4
$ cat main.cpp
#include <iostream>... (6 Replies)
Discussion started by: migurus
6 Replies
8. AIX
Hello,
I'm currently trying to mix local and LDAP users on an AIX 7.1.
I've triied many things.
My LDAP Server in on a CentOS - OpenLDAP (which works fine with linux).
I'm currently stuck on AIX at how to declare LDAP AND Local users.
Here's what i did :
/usr/sbin/mksecldap -c -h 'ldap03'... (15 Replies)
Discussion started by: AIX_user_324891
15 Replies
LEARN ABOUT XFREE86
gccmakedep
gccmakedep(1) General Commands Manual gccmakedep(1) NAME
gccmakedep - create dependencies in makefiles using 'gcc -M' SYNOPSIS
gccmakedep [ -sseparator ] [ -fmakefile ] [ -a ] [ -- options -- ] sourcefile ... DESCRIPTION
The gccmakedep program calls 'gcc -M' to output makefile rules describing the dependencies of each sourcefile, so that make(1) knows which object files must be recompiled when a dependency has changed. By default, gccmakedep places its output in the file named makefile if it exists, otherwise Makefile. An alternate makefile may be speci- fied with the -f option. It first searches the makefile for a line beginning with # DO NOT DELETE or one provided with the -s option, as a delimiter for the dependency output. If it finds it, it will delete everything following this up to the end of the makefile and put the output after this line. If it doesn't find it, the program will append the string to the makefile and place the output after that. EXAMPLE
Normally, gccmakedep will be used in a makefile target so that typing 'make depend' will bring the dependencies up to date for the make- file. For example, SRCS = file1.c file2.c ... CFLAGS = -O -DHACK -I../foobar -xyz depend: gccmakedep -- $(CFLAGS) -- $(SRCS) OPTIONS
The program will ignore any option that it does not understand, so you may use the same arguments that you would for gcc(1), including -D and -U options to define and undefine symbols and -I to set the include path. -a Append the dependencies to the file instead of replacing existing dependencies. -fmakefile Filename. This allows you to specify an alternate makefile in which gccmakedep can place its output. Specifying "-" as the file name (that is, -f-) sends the output to standard output instead of modifying an existing file. -sstring Starting string delimiter. This option permits you to specify a different string for gccmakedep to look for in the makefile. The default is "# DO NOT DELETE". -- options -- If gccmakedep encounters a double hyphen (--) in the argument list, then any unrecognized arguments following it will be silently ignored. A second double hyphen terminates this special treatment. In this way, gccmakedep can be made to safely ignore esoteric compiler arguments that might normally be found in a CFLAGS make macro (see the EXAMPLE section above). -D, -I, and -U options appearing between the pair of double hyphens are still processed normally. SEE ALSO
gcc(1), make(1), makedepend(1). AUTHOR
gccmakedep was written by the XFree86 Project based on code supplied by Hongjiu Lu. Colin Watson wrote this manual page, originally for the Debian Project, based partly on the manual page for makedepend(1). XFree86 Version 4.7.0 gccmakedep(1)