|
|
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 POSIX
uselib
USELIB(2) Linux Programmer's Manual USELIB(2) NAME
uselib - load shared library SYNOPSIS
#include <unistd.h> int uselib(const char *library); Note: No declaration of this system call is provided in glibc headers; see NOTES. DESCRIPTION
The system call uselib() serves to load a shared library to be used by the calling process. It is given a pathname. The address where to load is found in the library itself. The library can have any recognized binary format. RETURN VALUE
On success, zero is returned. On error, -1 is returned, and errno is set appropriately. ERRORS
In addition to all of the error codes returned by open(2) and mmap(2), the following may also be returned: EACCES The library specified by library does not have read or execute permission, or the caller does not have search permission for one of the directories in the path prefix. (See also path_resolution(7).) ENFILE The system-wide limit on the total number of open files has been reached. ENOEXEC The file specified by library is not an executable of a known type; for example, it does not have the correct magic numbers. CONFORMING TO
uselib() is Linux-specific, and should not be used in programs intended to be portable. NOTES
This obsolete system call is not supported by glibc. No declaration is provided in glibc headers, but, through a quirk of history, glibc versions before 2.23 did export an ABI for this system call. Therefore, in order to employ this system call, it was sufficient to manually declare the interface in your code; alternatively, you could invoke the system call using syscall(2). In ancient libc versions, uselib() was used to load the shared libraries with names found in an array of names in the binary. Since libc 4.3.2, startup code tries to prefix these names with "/usr/lib", "/lib" and "" before giving up. In libc 4.3.4 and later these names are looked for in the directories found in LD_LIBRARY_PATH, and if not found there, prefixes "/usr/lib", "/lib" and "/" are tried. From libc 4.4.4 on only the library "/lib/ld.so" is loaded, so that this dynamic library can load the remaining libraries needed (again using this call). This is also the state of affairs in libc5. glibc2 does not use this call. Since Linux 3.15, this system call is available only when the kernel is configured with the CONFIG_USELIB option. SEE ALSO
ar(1), gcc(1), ld(1), ldd(1), mmap(2), open(2), dlopen(3), capabilities(7), ld.so(8) COLOPHON
This page is part of release 4.15 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/. Linux 2017-09-15 USELIB(2)