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
DYLD(1) 						      General Commands Manual							   DYLD(1)

NAME
dyld - the dynamic link editor SYNOPSIS
DYLD_FRAMEWORK_PATH DYLD_FALLBACK_FRAMEWORK_PATH DYLD_LIBRARY_PATH DYLD_FALLBACK_LIBRARY_PATH DYLD_INSERT_LIBRARIES DYLD_FORCE_FLAT_NAMESPACE DYLD_IMAGE_SUFFIX DYLD_PRINT_LIBRARIES DYLD_PRINT_LIBRARIES_POST_LAUNCH DYLD_EBADEXEC_ONLY DYLD_BIND_AT_LAUNCH DYLD_DEAD_LOCK_HANG DYLD_PREBIND_DEBUG DYLD_ABORT_MULTIPLE_INITS DYLD_NEW_LOCAL_SHARED_REGIONS DYLD_NO_FIX_PREBINDING DYLD_TRACE DESCRIPTION
The dynamic linker uses the following environment variables. They affect any program that uses the dynamic linker. DYLD_FRAMEWORK_PATH This is a colon separated list of directories that contain frameworks. The dynamic linker searches these directories before it searches for the framework by its install name. It allows you to test new versions of existing frameworks. (A framework is a library install name that ends in the form XXX.framework/Versions/YYY/XXX or XXX.framework/XXX, where XXX and YYY are any name.) For each framework that a program uses, the dynamic linker looks for the framework in each directory in DYLD_FRAMEWORK_PATH in turn. If it looks in all the directories and can't find the framework, it searches the directories in DYLD_LIBRARY_PATH in turn. If it still can't find the framework, it then searches DYLD_FALLBACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH in turn. Use the -L option to otool(1). to discover the frameworks and shared libraries that the executable is linked against. DYLD_FALLBACK_FRAMEWORK_PATH This is a colon separated list of directories that contain frameworks. It is used as the default location for frameworks not found in their install path. By default, it is set to $(HOME)/Library/Frameworks:/Library/Frameworks:/Network/Library/Frameworks:/System/Library/Frameworks DYLD_LIBRARY_PATH This is a colon separated list of directories that contain libraries. The dynamic linker searches these directories before it searches the default locations for libraries. It allows you to test new versions of existing libraries. For each library that a program uses, the dynamic linker looks for it in each directory in DYLD_LIBRARY_PATH in turn. If it still can't find the library, it then searches DYLD_FALLBACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH in turn. Use the -L option to otool(1). to discover the frameworks and shared libraries that the executable is linked against. DYLD_FALLBACK_LIBRARY_PATH This is a colon separated list of directories that contain libraries. It is used as the default location for libraries not found in their install path. By default, it is set to $(HOME)/lib:/usr/local/lib:/lib:/usr/lib. DYLD_INSERT_LIBRARIES This is a colon separated list of dynamic libraries to load before the ones specified in the program. This lets you test new mod- ules of existing dynamic shared libraries that are used in flat-namespace images by loading a temporary dynamic shared library with just the new modules. Note that this has no effect on images built a two-level namespace images using a dynamic shared library unless DYLD_FORCE_FLAT_NAMESPACE is also used. DYLD_FORCE_FLAT_NAMESPACE Force all images in the program to be linked as flat-namespace images and ignore any two-level namespace bindings. This may cause programs to fail to execute with a multiply defined symbol error if two-level namespace images are used to allow the images to have multiply defined symbols. DYLD_IMAGE_SUFFIX This is set to a string of a suffix to try to be used for all shared libraries used by the program. For libraries ending in ".dylib" the suffix is applied just before the ".dylib". For all other libraries the suffix is appended to the library name. This is useful for using conventional "_profile" and "_debug" libraries and frameworks. DYLD_PRINT_LIBRARIES When this is set, the dynamic linker writes to file descriptor 2 (normally standard error) the filenames of the libraries the pro- gram is using. This is useful to make sure that the use of DYLD_LIBRARY_PATH is getting what you want. DYLD_PRINT_LIBRARIES_POST_LAUNCH This does the same as DYLD_PRINT_LIBRARIES but the printing starts after the program gets to its entry point. DYLD_EBADEXEC_ONLY When this is set, the dynamic linker does all of the work needed to launch a program without launching it. This either prints the cause why the program could not be launched or prints a message saying the program could be launched. This variable can be used a supplement to the program ebadexec(1) to determine why a program can't be launched. For programs that should not have any undefined symbols when launched the DYLD_BIND_AT_LAUNCH can also be set to check this. DYLD_BIND_AT_LAUNCH When this is set, the dynamic linker binds all undefined symbols the program needs at launch time. This includes function symbols that can are normally lazily bound at the time of their first call. DYLD_DEAD_LOCK_HANG When this is set, the dynamic linker enters a loop that hangs the program if a thread doing a dynamic linker operation attempts to start another dynamic linker operation before completing the first. This lets you attach a debugger to the process instead of let- ting the process exit. DYLD_PREBIND_DEBUG When this is set, the dynamic linker prints diagnostics about launching prebound programs and libraries. This lets you determine why a program is not being launched prebound. You can view the recorded library time stamps with the -Lv option to otool(1). DYLD_ABORT_MULTIPLE_INITS When this is set, the dynamic linker causes the program to abort when multiple library initialization routines are being run which can happen if code called via a library initialization routine makes a call to a dyld API. Then under the debugger it is easy to do a back trace and find the code that is making the call to a dyld API via code called from a library initialization routine For secure programs that are UNIX set uid or set gid, the dynamic linker will not use the dyld environment variables for path searching and library insertion, unless the program is run as the real user. For secure programs, the dynamic linker clears out the value of the dyld path and insertion environment variables. This is so that if a program is exec(2)'ed from a secure program too will not have it's libraries searched for, as well. For statically linked secure programs that exec(2) other programs that might use the dynamic linker, they too should clear out the values of the dyld path and insertion environment variables. DYLD_NEW_LOCAL_SHARED_REGIONS When set, the dynamic linker directs the system to provide a new set of shared regions as the repository for library load requests for dynamic libraries built with MH_SPLIT_SEGS (split shared libraries). Split shared libraries reside in a defined contiguous region of address space in all dynamic linker runtime processes. This space is backed by named regions or sub-maps. These sub-maps are owned by the system and items which are to mapped into them must be mapped via the load_shared_file(2) call. The use of sub-maps promotes a high degree of system resource sharing between the pro- cesses which incorporate and use them. However, some processes require either additional or different libraries to be loaded into the shared region. While there is some space available within the shared region for alternate and new shared libraries, it is inap- propriate to use that area for temporary or private libraries. Setting the DYLD_NEW_LOCAL_SHARED_REGIONS flag will cause all chil- dren of the current process to have their own set of sub-maps. In this way the libraries found in the children's submaps will not be caused to be present in the submaps shared by the rest of the system. DYLD_NEW_LOCAL_SHARED_REGIONS should be set by anyone wishing to run non-standard or temporary split shared libraries by setting an explicit path to point to them. i.e. by using the DYLD_LIBRARY_PATH environment variable instead of changing the root by executing a chroot(2) call. DYLD_TRACE Cause dyld to put tracing information in the kernel trace buffer for its operations. DYLD_NO_FIX_PREBINDING Causes dyld not to run /usr/bin/fix_prebinding on executables that are launched which had prebinding information that could not be used for the launch. SEE ALSO
libtool(1), ld(1), otool(1), redo_prebinding(1) Apple Computer, Inc. July 24, 2002 DYLD(1)
All times are GMT -4. The time now is 04:14 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy