Sponsored Content
Full Discussion: Makefile Mix for C and C++
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
Old 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! Smilie 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

How to grep mix of numbers and systemdate?

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

mix fc and tape devices

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

Makefile problem - How to run module load in a Makefile

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

ZFS Pool Mix-up

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

How to mix the contents of 2 files into a new file?

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

Help with Simple Multi-Level Makefile (Extremely New at Makefile)

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

makefile for mix of C and C++ modules

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

Mix LDAP and LOCAL user on 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
STRIP(1)						      General Commands Manual							  STRIP(1)

NAME
strip - remove symbols SYNOPSIS
strip [ option ] name ... DESCRIPTION
strip removes or modifies the symbol table attached to the output of the assembler and link editor. This is useful to save space after a program has been debugged and to limit dynamically bound symbols. strip no longer removes relocation entries under any condition. Instead, it updates the external relocation entries (and indirect symbol table entries) to reflect the resulting symbol table. strip prints an error message for those symbols not in the resulting symbol table that are needed by an external relocation entry or an indirect symbol table. The link editor ld(1) is the only program that can strip relocation entries and know if it is safe to do so. When strip is used with no options on an executable file, it checks that file to see if it uses the dynamic link editor. If it does, the effect of the strip command is the same as using the -u and -r options. If the file does not use the dynamic link editor, the effect of strip without any options is the same as using the -s option of ld(1). The options -S, -x, and -X have the same effect as the ld(1) options. The options to strip(1) can be combined to trim the symbol table to just what is desired. You should trim the symbol table of files used with dynamic linking so that only those symbols intended to be external interfaces are saved. Files used with dynamic linking include executables, objects that are loaded (usually bundles), and dynamic shared libraries. Only global symbols are used by the dynamic linking process. You should strip all non-global symbols. When an executable is built with all its dependent dynamic shared libraries, it is typically stripped with: % strip -u -r executable which saves all undefined symbols (usually defined in the dynamic shared libraries) and all global symbols defined in the executable refer- enced by the dynamic libraries (as marked by the static link editor when the executable was built). This is the maximum level of striping for an executable that will still allow the program to run correctly with its libraries. If the executable loads objects, however, the global symbols that the objects reference from the executable also must not be stripped. In this case, you should list the global symbols that the executable wants to allow the objects to reference in a file, and those global sym- bols are then saved when the executable is stripped. For example: % strip -u -r -s interface_symbols executable where the file interface_symbols would contain only those global symbols from the executable that the executable wants the loaded objects to have access to. For objects that will be loaded into an executable, you should trim the symbol table to limit the global symbols the executable will see. This would be done with: % strip -s interface_symbols -u object which would leave only the undefined symbols and symbols listed in the file interface_symbols in the object file. In this case, strip(1) has updated the relocation entries and indirect symbol table to reflect the new symbol table. For dynamic shared libraries, the maximum level of stripping is usually -x (to remove all non-global symbols). STRIPPING FILES FOR USE WITH RUNTIME LOADED CODE
Trimming the symbol table for programs that load code at runtime allows you to control the interface that the executable wants to provide to the objects that it will load; it will not have to publish symbols that are not part of its interface. For example, an executable that wishes to allow only a subset of its global symbols but all of the statically linked shared library's globals to be used would be stripped with: % strip -s interface_symbols -A executable where the file interface_symbols would contain only those symbols from the executable that it wishes the code loaded at runtime to have access to. Another example is an object that is made up of a number of other objects that will be loaded into an executable would built and then stripped with: % ld -o relocatable.o -r a.o b.o c.o % strip -s interface_symbols -u relocatable.o which would leave only the undefined symbols and symbols listed in the file interface_symbols in the object file. In this case strip(1) has updated the relocation entries to reflect the new symbol table. OPTIONS
The first set of options indicate symbols that are to be save in the resulting output file. -u Save all undefined symbols. This is intended for use with relocatable objects to save symbols referred to by external relocation entries. Note that common symbols are also referred to by external relocation entries and this flag does not save those symbols. -r Save all symbols referenced dynamically. -s filename Save the symbol table entries for the global symbols listed in filename. The symbol names listed in filename must be one per line. Leading and trailing white space are not part of the symbol name. Lines starting with # are ignored, as are lines with only white space. -R filename Remove the symbol table entries for the global symbols listed in filename. This file has the same format as the -s filename option above. This option is usually used in combination with other options that save some symbols, -S, -x, etc. -i Ignore symbols listed in the -s filename or -R filename options that are not in the files to be stripped (this is normally an error). -d filename Save the debugging symbol table entries for each source file name listed in filename. The source file names listed in filename must be one per line with no other white space in the file except the newlines on the end of each line. And they must be just the base name of the source file without any leading directories. -A Save all global absolute symbols except those with a value of zero, and save Objective C class symbols. This is intended for use of programs that load code at runtime and want the loaded code to use symbols from the shared libraries (this is only used with NEXTSTEP 3.3 and earlier releases). -n Save all N_SECT global symbols. This is intended for use with executable programs in combination with -A to remove the symbols needed for correct static link editing which are not needed for use with runtime loading interfaces where using the -s filename would be too much trouble (this is only used with NEXTSTEP 3.3 and earlier releases). These options specify symbols to be removed from the resulting output file. -S Remove the debugging symbol table entries (those created by the -g option to cc(1) and other compilers). -X Remove the local symbols whose names begin with `L'. -x Remove all local symbols (saving only global symbols). -c Remove the section contents of a dynamic library creating a stub library output file. And the last options: - Treat all remaining arguments as file names and not options. -o output Write the result into the file output. SEE ALSO
ld(1), cc(1) LIMITATIONS
Not every layout of a Mach-O file can be stripped by this program. But all layouts produced by the Apple compiler system can be stripped. Apple Computer, Inc. April 21, 2001 STRIP(1)
All times are GMT -4. The time now is 08:30 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy