Export lib in linux

Изучаем команды Linux: export

1. Введение

Export — это одна из встроенных команд оболочки bash, поэтому она является неотъемлемой частью вашей командной строки. Она очень проста в использовании, так как синтаксис export допускает использование всего трех опций командной строки. В целом команда export отмечает переменную окружения для экспорта с любым новым дочерним процессом, и это позволяет дочернему процессу наследовать все отмеченные переменные. В данной статье этот процесс будет описан более подробно.

2. Часто используемые опции

-p
выводит список всех имен, экспортированных в текущей оболочке
-n
удаляет имена из списка экспорта
-f
имена экспортируются как функции

3. Основы export

Подумайте над следующим примером:

Строка 1: создается новая переменная с именем «a», содержащая строку «linuxcareer.com».
Строка 2: мы используем команду echo, чтобы вывести содержимое переменной «a».
Строка 3: мы создаем дочерний экземпляр оболочки bash.
Строка 4: переменная «a» теперь не определена.

Из приведенного выше примера можно видеть, что любой дочерний процесс, ответвляющийся от родительского процесса, по умолчанию не наследует переменные родителя. Для этого и нужна команда export. Что произойдет, если мы используем команду export в вышеприведенном примере?

Теперь в строке 3 мы использовали команду export, чтобы экспортировать переменную «a» в созданный новый дочерний процесс. В результате переменная «a» все еще содержит строку «linuxcareer.com», даже после создания нового экземпляра оболочки bash. Здесь важно отметить, что для успешного экспорта «a» необходимо, чтобы процесс, в который экспортируется переменная, ответвлялся от того родительского процесса, из которого экспортируется эта переменная. Связь между дочерним и родительским процессами описана ниже.

4. Дочерние и родительские процессы

В этом разделе мы коротко опишем взимосвязь между дочерним и родительским процессом. Все процессы могут быть родительскими и дочерними одновременно. Единственным исключением является процесс init, который всегда имеет PID (ID процесса) 1. Поэтому init является родительским для всех процессов, запущенных в системе Linux.

Любой создаваемый процесс имеет родительский процесс, из которого он создается, и может быть определен как потомок этого родительского процесса. Например:

Строка 1: вывести PID текущей командной оболочки — 27861
Строка 2: создать новый дочерний процесс из процесса с ID 27861
Строка 3: вывести PID текущей командной оболочки — 28034
Строка 4: вывести список дочерних процессов для PID 27861 с помощью команды ps

При создании нового дочернего процесса команда export просто обеспечивает, что все экспортируемые переменные родительского процесса доступны в дочернем процессе.

5. Использование команды export

Теперь, изучив основы, мы можем продолжить детальное исследование команды export. При использовании команды безо всяких опций и аргументов она просто выводит имена всех переменных, отмеченных для экспорта в дочерние процессы. То же самое происходит при использовании опции -p:

Как было показано выше, для экспорта переменной мы просто используем имя переменной в качестве аргумента команды export.

Как вы можете видеть, после экспорта переменной MYVAR, она будет показываться в списке экспортируемых переменных (строка 4). Приведенный выше пример можно сократить, используя команду export сразу при присваивании значения переменной.

Наиболее широко команда export применяется для объявления переменной оболочки PATH:

В этом примере мы включаем дополнительный путь /usr/local/bin в существующее определение PATH.

6. Экспорт функций командной оболочки

Используя опцию -f, команда export может быть также использована для экспорта функций. В примере ниже мы создаем функцию оболочки под именем printname, которая просто выводит строку «Linuxcareer.com» с помощью команды echo.

7. Удаление имен из списка экспорта

Выполнив один из вышеприведенных примеров, мы имеет переменную MYVAR, определенную в списке экспорта.

Чтобы удалить переменную из списка экспорта, необходимо использовать опцию -n.

8. Заключение

В этой статье рассмотрены основы использования команды export. Чтобы узнать больше подробностей, используйте команду:

Источник

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Управление библиотеками в Linux

Когда библиотекарь — пингвин

4 минуты чтения

В данной статье мы посмотрим, что такое статические и динамические библиотеки. Местоположение библиотек по умолчанию. Определение используемых библиотек. Загрузка библиотек.

Мини — курс по виртуализации

Знакомство с VMware vSphere 7 и технологией виртуализации в авторском мини — курсе от Михаила Якобсена

Библиотеки это набор функций, которые могут использоваться в различных программах. Библиотеки могут быть статические (библиотека привязывается к определенной программе или софт содержит данную библиотеку в своем теле.) и динамическими (библиотеки грузятся в оперативную память и используются). Плюсы первого варианта нет проблемы совместимости, т. к. софт уже в себе содержит библиотеку, библиотека всегда с собой. Но при этом программы становятся большие по размеры и т.к каждая может загружать свои библиотеки, а иногда и одинаковые. Второй вариант значительно лучше, сами программы по своему размеру меньше. Библиотека загружается один раз в оперативку. И следующая программа, которой необходимы такие же функции, берет и использует эти данные.

По умолчанию библиотеки в Linux находятся в двух папках. Это корневая папка /lib в ней находятся библиотеки, которые используют программы, расположенные в корневой папке /bin.

И есть вторая папка /usr/lib. В ней находятся библиотеки, которые используют программы расположенные /usr/bin. Пути к библиотекам указаны файле /etc/ld.so.conf. Данный файл можно просмотреть стандартным способом, через утилиту cat.

Видим, что написано включить все библиотеки, которые расположены по пути, указанном в файле. Те которые оканчиваются на .conf. Он просто включает в себя все настройки, которые находятся в конфигурационных файлах, в данной директории. Переходим в данную директорию.

В данной директории мы можем видеть 2 файла конфигурации, в зависимости от версии и наполнения операционной системы их может быть и больше. Ну и соответственно в конфигурационных файлах находятся пути к директориям, где лежат необходимые для работы библиотеки. Если мы ставим какое, то свое программное обеспечение, которому необходимы дополнительные библиотеки, не идущие в составе дистрибутива linux, то в данной директории может создаться свой конфигурационный файл. Например: если мы используем систему виртуализации VMware, то к каждой VM устанавливаем VMware tools то данное программное обеспечение создаст свой конфигурационный файл с путями для своих библиотек.

Переходим в директорию cd /etc/ и отсортируем так, чтобы в результатах все, что содержит ld.

Видим 3 основных конфигурационных файла. ld.so.conf — это файл конфигурации в котором написано откуда брать дополнительные библиотеки. Директория ls.so.conf.d в которой находятся дополнительные конфигурационные файлы и ld.so.cache это кэш библиотек. Он у нас выстраивается каждый раз для того, чтобы программы при необходимости при запросе библиотек не копались в файлах, а сразу брали из загруженного в оперативную память кэша. Т.е. если мы вносим какие-то изменения в файл конфигурации, добавляем какие-то конфигурационные файлы нам необходимо обновить этот кэш. Кэш обновляется командой ldconfig. Этого, собственно, достаточно, чтобы прогрузить все библиотеки в кэш.

Давайте посмотрим, как, определить какими библиотеками пользуется какая программа.

Для этого мы будем использовать команду ldd и путь к бинарному файлу. Например: Программа ls которая используется для вывода списка файлов в каталоге. Она находится в каталоге /bin/ls.

В результате получим мы следующее:

Мы видим, какие so использует данная программа и соответственно ссылки на них, где они расположены, собственно, so — это наши библиотеки в данном случае.

Возможно добавление библиотек вручную, это может потребоваться если мы ставим совершенно стороннее программное обеспечение, которое очень трудно взаимодействует с Linux или устаревшее. Т.е. которое само не может создать конфигурационный файл и разнести библиотеки в системные директории Linux. Если мы хотим сделать это вручную, тогда нам необходим тот самый файл /etc/ld.so.conf. В данный файл мы можем дописать путь к файлу конфигурации библиотек тех, которые нам нужны. Либо есть более легкий вариант с использованием переменной export LD_LIBRARY_PATH и указать путь к тем особенным библиотекам, которые будет использовать наша «особенная» программа. Обычно все стороннее программное обеспечение устанавливается в папку /opt. Итоговый вариант будет выглядеть как: export LD_LIBRARY_PATH=/opt/soft/lib и когда пройдет экспорт, у нас попробует погрузится из этого пути библиотека, но перед этим необходимо не забыть сделать ldconfig.

Онлайн курс по Linux

Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps

Источник

Export Command in Linux Explained

The export command in Linux is used for creating environment variables. You can use it like this:

or a shorthand like this to assign it a value immediately:

You can see the value of exported variables with the echo command:

To make the changes permanent, you should add it to the

That was just the quick summary. Let’s see it in details to understand it better.

Understanding how export command works

In the example below, I declare a shell variable var and assign it a value 3. It’s a shell variable for now.

If I exit the terminal and open a new terminal, this shell variable will disappear. If I want to use this variable in a shell script, it won’t work. Similarly, if I switch user (and thus initiating a new shell with this user), this shell variable won’t be available:

Now, let’s go back to the previous user (and thus the previous shell where I declared the shell variable). You can see that the variable still exists here (because we didn’t terminate this shell session yet):

So, now if I use the export command on the variable var here, it will become an environment variable and it will be available to all the subshells, users and shell scripts in this session.

You can check all the environment variables using the printenv command:

Make exported shell variables ‘permanent’ with bashrc file

But the struggle doesn’t end here. If you close the session, exit the terminal, log out or reboot your system, your environment variable will disappear again.

This is why it’s a common practice to add the export commands to the runtime configuration (rc) file of your shell.

Every shell has this rc file located in the user’s home directory which is used to determine variables and other configuration when the shell is started. As a user, you can use this rc file to customize your shell and its behavior.

If you are using bash shell, you should have a bashrc file at

/.bashrc. You can either edit this file in a text editor like Vim or you can just append export var=3 (or whatever you are exporting) to this file.

Once done, you should use the source command to make the changes available immediately.

A good practice is to keep all the user defined environment variables at one place.

Why use export command?

One of the most common use of the export command is when you want to add something to the path so that your Linux system will find the certain command/executable file.

For example, if you installed maven and you want to be able to run it, you should add the directory location of maven executables to the path like this:

What does it do? It adds this directory location to the path. When you try to run a command in Linux, your system searches for its executable (usually in bin directory) in the directories mentioned in the PATH variable.

Bonus Tip: Remove a variable from exported list

Suppose you want to remove an ‘exported’ variable. You can use the negate option in this fashion:

Keep in mind that this will not reset the value of the variable. It will just turn the exported global variable into a local variable. It will continue to have the same value you had set earlier.

If you want to remove the variable from the exported list as well as remove its assigned value, use the unset option:

I hope you have a better idea of the export command in Linux now. If you have doubts, please feel free to ask in the comment section.

Источник

Static, Shared Dynamic and Loadable Linux Libraries

This tutorial discusses the philosophy behind libraries and the creation and use of C/C++ library «shared components» and «plug-ins». The various technologies and methodologies used and insight to their appropriate application, is also discussed. In this tutorial, all libraries are created using the GNU Linux compiler.

Related YoLinux Tutorials:

Libraries employ a software design also known as «shared components» or «archive libraries», which groups together multiple compiled object code files into a single file known as a library. Typically C functions/C++ classes and methods which can be shared by more than one application are broken out of the application’s source code, compiled and bundled into a library. The C standard libraries and C++ STL are examples of shared components which can be linked with your code. The benefit is that each and every object file need not be stated when linking because the developer can reference the library collective. This simplifies the multiple use and sharing of software components between applications. It also allows application vendors a way to simply release an API to interface with an application. Components which are large can be created for dynamic use, thus the library can remain separate from the executable reducing it’s size and thus less disk space is used for the application. The library components are then called by various applications for use when needed.

Benefits include:

• Component reuse: update one library, shared resource takes up less disk space.
• Version management: Linux libraries can cohabitate old and new versions on a single system.
• Component Specialization: niche and specialized developers can focus on their core competency on a single library. Simplifies testing and verification.

There are two Linux C/C++ library types which can be created:

1. Static libraries (.a): Library of object code which is linked with, and becomes part of the application.
2. Dynamically linked shared object libraries (.so): There is only one form of this library but it can be used in two ways.
   1. Dynamically linked at run time. The libraries must be available during compile/link phase. The shared objects are not included into the executable component but are tied to the execution.
   2. Dynamically loaded/unloaded and linked during execution (i.e. browser plug-in) using the dynamic linking loader system functions.

Library naming conventions:

Consider the following compile and link command: gcc src-file.c -lm -lpthread
The libraries referenced in this example for inclusion during linking are the math library («m») and the thread library («pthread»). They are found in /usr/lib/libm.a and /usr/lib/libpthread.a.

Note: The GNU compiler now has the command line option «-pthread» while older versions of the compiler specify the pthread library explicitly with «-lpthread». Thus now you are more likely to see gcc src-file.c -lm -pthread

How to generate a static library (object code archive file):

• Compile: cc -Wall -c ctest1.c ctest2.c
  Compiler options:
  • -Wall: include warnings. See man page for warnings specified.
• Create library «libctest.a»: ar -cvq libctest.a ctest1.o ctest2.o
• List files in library: ar -t libctest.a
• Linking with the library:
  • cc -o executable-name prog.c libctest.a
  • cc -o executable-name prog.c -L/path/to/library-directory -lctest
• Example files:
  • ctest1.c
  • ctest2.c
  • prog.c

Historical note: After creating the library it was once necessary to run the command: ranlib ctest.a. This created a symbol table within the archive. Ranlib is now embedded into the «ar» command.

Note for MS/Windows developers: The Linux/Unix «.a» library is conceptually the same as the Visual C++ static «.lib» libraries.

How to generate a shared object: (Dynamically linked object library file.) Note that this is a two step process.

1. Create object code
2. Create library
3. Optional: create default version using a symbolic link.

Library creation example: This creates the library libctest.so.1.0 and symbolic links to it.

It is also valid to cascade the linkage: If you look at the libraries in /lib/ and /usr/lib/ you will find both methodologies present. Linux developers are not consistent. What is important is that the symbolic links eventually point to an actual library.

• -Wall: include warnings. See man page for warnings specified.
• -fPIC: Compiler directive to output position independent code, a characteristic required by shared libraries. Also see «-fpic».
• -shared: Produce a shared object which can then be linked with other objects to form an executable.
• -Wl,options: Pass options to linker.
  In this example the options to be passed on to the linker are: «-soname libctest.so.1«. The name passed with the «-o» option is passed to gcc.
• Option -o: Output of operation. In this case the name of the shared object to be output will be «libctest.so.1.0«

• The link to /opt/lib/libctest.so allows the naming convention for the compile flag -lctest to work.
• The link to /opt/lib/libctest.so.1 allows the run time binding to work. See dependency below.

Compile main program and link with shared object library:

Compiling for run-time linking with a dynamically linked libctest.so.1.0: Use: Where the name of the library is libctest.so. (This is why you must create the symbolic links or you will get the error «/usr/bin/ld: cannot find -lctest».)
The libraries will NOT be included in the executable but will be dynamically linked during run-time execution.

The shared library dependencies of the executable can be listed with the command: ldd name-of-executable

Example: ldd prog [Potential Pitfall] : Unresolved errors within a shared library may cause an error when the library is loaded. Example:

Error message at run-time:

The first three libraries show that there is a path resolution. The last two are problematic.

The fix is to resolve dependencies of the last two libraries when linking the library libname-of-lib.so:

• Add the unresolved library path in /etc/ld.so.conf.d/name-of-lib-x86_64.conf and/or /etc/ld.so.conf.d/name-of-lib-i686.conf
  Reload the library cache (/etc/ld.so.cache) with the command: sudo ldconfig
  or
• Add library and path explicitly to the compiler/linker command: -lname-of-lib -L/path/to/lib
  or
• Add the library path to the environment variable to fix run-time dependency:
  export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/lib

• Set path: export LD_LIBRARY_PATH=/opt/lib:$LD_LIBRARY_PATH
• Run: prog

Example with code:

Using the example code above for ctest1.c, ctest2.c and prog.c

1. Compile the library functions: gcc -Wall -fPIC -c ctest1.c ctest2.c
2. Generate the shared library: gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0 ctest1.o ctest2.o
   This generates the library libctest.so.1.0
3. Move to lib/ directory:
   • sudo mv libctest.so.1.0 /opt/lib
   • sudo ln -sf /opt/lib/libctest.so.1.0 /opt/lib/libctest.so.1
   • sudo ln -sf /opt/lib/libctest.so.1 /opt/lib/libctest.so

   Compile program for use with a shared library: gcc -Wall -L/opt/lib prog.c -lctest -o prog
   [Potential Pitfall] : If the symbolic links are not created (above), you will get the following error: The reference to the library name -lctest refers to /opt/lib/libctest.so

4. Configure the library path (see below and choose one of three mechanisms).
   In this example we set the environment variable: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/lib
5. Run the program: ./prog
   [Potential Pitfall] : You get the following error if the library path is not set:

• gcc — GNU C compiler
• ld — The GNU Linker
• ldd — List library dependencies
• ldconfig — configure dynamic linker run time bindings (update cache /etc/ld.so.cache)

In order for an executable to find the required libraries to link with during run time, one must configure the system so that the libraries can be found. Methods available: (Do at least one of the following)

Add library directories to be included during dynamic linking to the file /etc/ld.so.conf

Add the library path to this file and then execute the command (as root) ldconfig to configure the linker run-time bindings.
You can use the «-f file-name» flag to reference another configuration file if you are developing for different environments.
See man page for command ldconfig.

Add specified directory to library cache: (as root)
ldconfig -n /opt/lib
Where /opt/lib is the directory containing your library libctest.so
(When developing and just adding your current directory: ldconfig -n . Link with -L.)

This will NOT permanently configure the system to include this directory. The information will be lost upon system reboot.

Specify the environment variable LD_LIBRARY_PATH to point to the directory paths containing the shared object library. This will specify to the run time loader that the library paths will be used during execution to resolve dependencies.
(Linux/Solaris: LD_LIBRARY_PATH, SGI: LD_LIBRARYN32_PATH, AIX: LIBPATH, Mac OS X: DYLD_LIBRARY_PATH, HP-UX: SHLIB_PATH)

Example (bash shell): export LD_LIBRARY_PATH=/opt/lib:$LD_LIBRARY_PATH or add to your

This instructs the run time loader to look in the path described by the environment variable LD_LIBRARY_PATH, to resolve shared libraries. This will include the path /opt/lib.

Library paths used should conform to the «Linux Standard Base» directory structure.

ar: list object files in archive library

This will list all of the object files held in the archive library: Also see: Man page for ar

nm: list symbols: object files, archive library and shared library

The command «nm» lists symbols contained in object files:

The command «nm» lists symbols contained in the archive library:

Object symbols in static archive libraries are categorized using the source and object file hierarchy of the library:

The command «nm» lists symbols contained in the object file or shared library.

Use the command nm -D libctest.so.1.0
(or nm --dynamic libctest.so.1.0)

Note that other platforms (Cygwin) may not respond to «-D». Try nm -gC libctest.so.1.0

Also see: Man page for nm

Symbol Type	Description
A	The symbol’s value is absolute, and will not be changed by further linking.
B	Un-initialized data section
D	Initialized data section
T	Normal code section
U	Undefined symbol used but not defined. Dependency on another library.
W	Doubly defined symbol. If found, allow definition in another library to resolve dependency.

Also see: objdump man page

readelf: list symbols in shared library

The command «readelf» command to list symbols contained in a shared library:

Use the command readelf -s /usr/lib64/libjpeg.so

Also see: readelf man page

Library versions should be specified for shared objects if the function interfaces are expected to change (C++ public/protected class definitions), more or fewer functions are included in the library, the function prototype changes (return data type (int, const int, . ) or argument list changes) or data type changes (object definitions: class data members, inheritance, virtual functions, . ).

The library version can be specified when the shared object library is created. If the library is expected to be updated, then a library version should be specified. This is especially important for shared object libraries which are dynamically linked. This also avoids the Microsoft «DLL hell» problem of conflicting libraries where a system upgrade which changes a standard library breaks an older application expecting an older version of the the shared object function.

Versioning occurs with the GNU C/C++ libraries as well. This often make binaries compiled with one version of the GNU tools incompatible with binaries compiled with other versions unless those versions also reside on the system. Multiple versions of the same library can reside on the same system due to versioning. The version of the library is included in the symbol name so the linker knows which version to link with.

One can look at the symbol version used: nm csub1.o

No version is specified in object code by default.

There is one GNU C/C++ compiler flag that explicitly deals with symbol versioning. Specify the version script to use at compile time with the flag: --version-script=your-version-script-file
Note: This is only useful when creating shared libraries. It is assumed that the programmer knows which libraries to link with when static linking. Run-time linking allows opportunity for library incompatibility.

GNU/Linux, see examples of version scripts here: sysdeps/unix/sysv/linux/Versions

Some symbols may also get version strings from assembler code which appears in glibc headers files. Look at include/libc-symbols.h.

Example: nm /lib/libc.so.6 | more

Note the use of a version script.

Library referencing a versioned library: nm /lib/libutil-2.2.5.so

These libraries are dynamically loaded / unloaded and linked during execution. Useful for creating a «plug-in» architecture.

Prototype include file for the library: ctest.h

Load and unload the library libctest.so (created above), dynamically:

gcc -rdynamic -o progdl progdl.c -ldl

• dlopen("/opt/lib/libctest.so", RTLD_LAZY);
  Open shared library named «libctest.so«.
  The second argument indicates the binding. See include file dlfcn.h.
  Returns NULL if it fails.
  Options:
  • RTLD_LAZY: If specified, Linux is not concerned about unresolved symbols until they are referenced.
  • RTLD_NOW: All unresolved symbols resolved when dlopen() is called.
  • RTLD_GLOBAL: Make symbol libraries visible.
• dlsym(lib_handle, "ctest1");
  Returns address to the function which has been loaded with the shared library..
  Returns NULL if it fails.
  Note: When using C++ functions, first use nm to find the «mangled» symbol name or use the extern "C" construct to avoid name mangling.
  i.e. extern "C" void function-name();

Object code location: Object code archive libraries can be located with either the executable or the loadable library. Object code routines used by both should not be duplicated in each. This is especially true for code which use static variables such as singleton classes. A static variable is global and thus can only be represented once. Including it twice will provide unexpected results. The programmer can specify that specific object code be linked with the executable by using linker commands which are passed on by the compiler.

Use the «-Wl» gcc/g++ compiler flag to pass command line arguments on to the GNU «ld» linker.

Example makefile statement: g++ -rdynamic -o appexe $(OBJ) $(LINKFLAGS) -Wl,--whole-archive -L -laa -Wl,--no-whole-archive $(LIBS)

• —whole-archive: This linker directive specifies that the libraries listed following this directive (in this case AA_libs) shall be included in the resulting output even though there may not be any calls requiring its presence. This option is used to specify libraries which the loadable libraries will require at run time.
• -no-whole-archive: This needs to be specified whether you list additional object files or not. The gcc/g++ compiler will add its own list of archive libraries and you would not want all the object code in the archive library linked in if not needed. It toggles the behavior back to normal for the rest of the archive libraries.

• dlopen() — gain access to an executable object file
• dclose() — close a dlopen object
• dlsym() — obtain the address of a symbol from a dlopen object
• dlvsym() — Programming interface to dynamic linking loader.
• dlerror() — get diagnostic information

C++ and name mangling:

When running the above «C» examples with the «C++» compiler one will quickly find that «C++» function names get mangled and thus will not work unless the function definitions are protected with extern "C"<>.

Note that the following are not equivalent:

The following are equivalent:

Dynamic loading of C++ classes:

The dynamic library loading routines enable the programmer to load «C» functions. In C++ we would like to load class member functions. In fact the entire class may be in the library and we may want to load and have access to the entire object and all of its member functions. Do this by passing a «C» class factory function which instantiates the class.

The class «.h» file:

The class «.cpp» file:

Main executable which calls the loadable libraries:

Pitfalls:

• The new/delete of the C++ class should both be provided by the executable or the library but not split. This is so that there is no surprise if one overloads new/delete in one or the other.

The Microsoft Windows equivalent to the Linux / Unix shared object («.so») is the «.dll». The Microsoft Windows DLL file usually has the extension «.dll», but may also use the extension «.ocx». On the old 16 bit windows, the dynamically linked libraries were also named with the «.exe» suffix. «Executing» the DLL will load it into memory.

The Visual C++ .NET IDE wizard will create a DLL framework through the GUI, and generates a «.def» file. This «module definition file» lists the functions to be exported. When exporting C++ functions, the C++ mangled names are used. Using the Visual C++ compiler to generate a «.map» file will allow you to discover the C++ mangled name to use in the «.def» file. The «SECTIONS» label in the «.def» file will define the portions which are «shared». Unfortunately the generation of DLLs are tightly coupled to the Microsoft IDE, so much so that I would not recommend trying to create one without it.

The Microsoft Windows C++ equivalent functions to libdl are the following functions:

• ::LoadLibrary() — dlopen()
• ::GetProcAddress() — dlsym()
• ::FreeLibrary() — dlclose()

[Potential Pitfall] : Microsoft Visual C++ .NET compilers do not allow the linking control that the GNU linker «ld» allows (i.e. —whole-archive, -no-whole-archive). All symbols need to be resolved by the VC++ compiler for both the loadable library and the application executable individually and thus it can cause duplication of libraries when the library is loaded. This is especially bad when using static variables (i.e. used in singleton patterns) as you will get two memory locations for the static variable, one used by the loadable library and the other used by the program executable. This breaks the whole static variable concept and the singleton pattern. Thus you can not use a static variable which is referenced by by both the loadable library and the application executable as they will be unique and different. To use a unique static variable, you must pass a pointer to that static variable to the other module so that each module (main executable and DLL library) can use the same instantiation. On MS/Windows you can use shared memory or a memory mapped file so that the main executable and DLL library can share a pointer to an address they both will use.

Cross platform (Linux and MS/Windows) C++ code snippet:

Источник