What kinds of files can be dynamically loaded?
Clash Royale CLAN TAG#URR8PPP
up vote
-1
down vote
favorite
Operating System Concepts says
8.1.4 Dynamic Loading
In our discussion so far, it has been necessary for the entire program
and all data of a process to be in physical memory for the process to
execute. The size of a process has thus been limited to the size of
physical memory. To obtain better memory-space utilization, we can use
dynamic loading. With dynamic loading, a routine is not loaded until
it is called. All routines are kept on disk in a relocatable load
format. The main program is loaded into memory and is executed. When a
routine needs to call another routine, the calling routine ï¬Ârst checks
to see whether the other routine has been loaded. If it has not, the
relocatable linking loader is called to load the desired routine into
memory and to update the programâÂÂs address tables to reï¬Âect this
change. Then control is passed to the newly loaded routine.
The advantage of dynamic loading is that a routine is loaded only when
it is needed. This method is particularly useful when large amounts of
code are needed to handle infrequently occurring cases, such as error
routines. In this case, although the total program size may be large,
the portion that is used (and hence loaded) may be much smaller.
Dynamic loading does not require special support from the operating
system. It is the responsibility of the users to design their programs
to take advantage of such a method. Operating systems may help the
programmer, however, by providing library routines to implement
dynamic loading.
8.1.5 Dynamic Linking and Shared Libraries
In "With dynamic loading, a routine is not loaded until it is called. All routines are kept on disk in a relocatable load format", what kinds of files have "a relocatable load format" in Linux,
- an ELF executable file,
- a .so shared library file,
- a .o object files?
Can they all be dynamically loaded?
http://refspecs.linuxbase.org/elf/gabi4+/ch4.intro.html says there are three kinds of ELF files: executable files, shared object files, and relocatable files. So does "a relocatable load format" in the quote above means only .o object file, not .so shared library file?
The book doesn't mention anything yet about shared library until Section 8.1.5, so Section 8.1.4 seems to me that dynamic loading is not necessarily loading a shared library into a user program, but may load something else. Is that true?
The last paragraph of section 8.1.4 seems to say that programmers need to perform dynamic loading explicitly. Does it refer to dlopen()
?
What kinds of files can dlopen()
accepts as its first argument, a .so shared library, a .o object file or an executable ELF file?
Thanks.
linux shared-library dynamic-loading
add a comment |Â
up vote
-1
down vote
favorite
Operating System Concepts says
8.1.4 Dynamic Loading
In our discussion so far, it has been necessary for the entire program
and all data of a process to be in physical memory for the process to
execute. The size of a process has thus been limited to the size of
physical memory. To obtain better memory-space utilization, we can use
dynamic loading. With dynamic loading, a routine is not loaded until
it is called. All routines are kept on disk in a relocatable load
format. The main program is loaded into memory and is executed. When a
routine needs to call another routine, the calling routine ï¬Ârst checks
to see whether the other routine has been loaded. If it has not, the
relocatable linking loader is called to load the desired routine into
memory and to update the programâÂÂs address tables to reï¬Âect this
change. Then control is passed to the newly loaded routine.
The advantage of dynamic loading is that a routine is loaded only when
it is needed. This method is particularly useful when large amounts of
code are needed to handle infrequently occurring cases, such as error
routines. In this case, although the total program size may be large,
the portion that is used (and hence loaded) may be much smaller.
Dynamic loading does not require special support from the operating
system. It is the responsibility of the users to design their programs
to take advantage of such a method. Operating systems may help the
programmer, however, by providing library routines to implement
dynamic loading.
8.1.5 Dynamic Linking and Shared Libraries
In "With dynamic loading, a routine is not loaded until it is called. All routines are kept on disk in a relocatable load format", what kinds of files have "a relocatable load format" in Linux,
- an ELF executable file,
- a .so shared library file,
- a .o object files?
Can they all be dynamically loaded?
http://refspecs.linuxbase.org/elf/gabi4+/ch4.intro.html says there are three kinds of ELF files: executable files, shared object files, and relocatable files. So does "a relocatable load format" in the quote above means only .o object file, not .so shared library file?
The book doesn't mention anything yet about shared library until Section 8.1.5, so Section 8.1.4 seems to me that dynamic loading is not necessarily loading a shared library into a user program, but may load something else. Is that true?
The last paragraph of section 8.1.4 seems to say that programmers need to perform dynamic loading explicitly. Does it refer to dlopen()
?
What kinds of files can dlopen()
accepts as its first argument, a .so shared library, a .o object file or an executable ELF file?
Thanks.
linux shared-library dynamic-loading
Where is this strange text from?
â schily
4 hours ago
It looks like the author of that text does not really understand how dynamic loading works.
â schily
4 hours ago
@schily Thanks. I am wondering what a relocatable format means? Do an executable, .so shared library, .o object file all have a relocatable format?
â Tim
4 hours ago
2
It's unfortunate that someone has (presumably) violated the Copyright of the 2009 book by posting it online. "No part of this publication may be reproduced..." -- and apparently there are many other such files on that jufiles website. Is there any indication that the website has acquired "prior written consent" from the publishers?
â Jeff Schaller
4 hours ago
1
Perhaps, besides the written quote in question, a regular old reference to the book would do? Title, author, editon, date, ISBN?
â Jeff Schaller
3 hours ago
add a comment |Â
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
Operating System Concepts says
8.1.4 Dynamic Loading
In our discussion so far, it has been necessary for the entire program
and all data of a process to be in physical memory for the process to
execute. The size of a process has thus been limited to the size of
physical memory. To obtain better memory-space utilization, we can use
dynamic loading. With dynamic loading, a routine is not loaded until
it is called. All routines are kept on disk in a relocatable load
format. The main program is loaded into memory and is executed. When a
routine needs to call another routine, the calling routine ï¬Ârst checks
to see whether the other routine has been loaded. If it has not, the
relocatable linking loader is called to load the desired routine into
memory and to update the programâÂÂs address tables to reï¬Âect this
change. Then control is passed to the newly loaded routine.
The advantage of dynamic loading is that a routine is loaded only when
it is needed. This method is particularly useful when large amounts of
code are needed to handle infrequently occurring cases, such as error
routines. In this case, although the total program size may be large,
the portion that is used (and hence loaded) may be much smaller.
Dynamic loading does not require special support from the operating
system. It is the responsibility of the users to design their programs
to take advantage of such a method. Operating systems may help the
programmer, however, by providing library routines to implement
dynamic loading.
8.1.5 Dynamic Linking and Shared Libraries
In "With dynamic loading, a routine is not loaded until it is called. All routines are kept on disk in a relocatable load format", what kinds of files have "a relocatable load format" in Linux,
- an ELF executable file,
- a .so shared library file,
- a .o object files?
Can they all be dynamically loaded?
http://refspecs.linuxbase.org/elf/gabi4+/ch4.intro.html says there are three kinds of ELF files: executable files, shared object files, and relocatable files. So does "a relocatable load format" in the quote above means only .o object file, not .so shared library file?
The book doesn't mention anything yet about shared library until Section 8.1.5, so Section 8.1.4 seems to me that dynamic loading is not necessarily loading a shared library into a user program, but may load something else. Is that true?
The last paragraph of section 8.1.4 seems to say that programmers need to perform dynamic loading explicitly. Does it refer to dlopen()
?
What kinds of files can dlopen()
accepts as its first argument, a .so shared library, a .o object file or an executable ELF file?
Thanks.
linux shared-library dynamic-loading
Operating System Concepts says
8.1.4 Dynamic Loading
In our discussion so far, it has been necessary for the entire program
and all data of a process to be in physical memory for the process to
execute. The size of a process has thus been limited to the size of
physical memory. To obtain better memory-space utilization, we can use
dynamic loading. With dynamic loading, a routine is not loaded until
it is called. All routines are kept on disk in a relocatable load
format. The main program is loaded into memory and is executed. When a
routine needs to call another routine, the calling routine ï¬Ârst checks
to see whether the other routine has been loaded. If it has not, the
relocatable linking loader is called to load the desired routine into
memory and to update the programâÂÂs address tables to reï¬Âect this
change. Then control is passed to the newly loaded routine.
The advantage of dynamic loading is that a routine is loaded only when
it is needed. This method is particularly useful when large amounts of
code are needed to handle infrequently occurring cases, such as error
routines. In this case, although the total program size may be large,
the portion that is used (and hence loaded) may be much smaller.
Dynamic loading does not require special support from the operating
system. It is the responsibility of the users to design their programs
to take advantage of such a method. Operating systems may help the
programmer, however, by providing library routines to implement
dynamic loading.
8.1.5 Dynamic Linking and Shared Libraries
In "With dynamic loading, a routine is not loaded until it is called. All routines are kept on disk in a relocatable load format", what kinds of files have "a relocatable load format" in Linux,
- an ELF executable file,
- a .so shared library file,
- a .o object files?
Can they all be dynamically loaded?
http://refspecs.linuxbase.org/elf/gabi4+/ch4.intro.html says there are three kinds of ELF files: executable files, shared object files, and relocatable files. So does "a relocatable load format" in the quote above means only .o object file, not .so shared library file?
The book doesn't mention anything yet about shared library until Section 8.1.5, so Section 8.1.4 seems to me that dynamic loading is not necessarily loading a shared library into a user program, but may load something else. Is that true?
The last paragraph of section 8.1.4 seems to say that programmers need to perform dynamic loading explicitly. Does it refer to dlopen()
?
What kinds of files can dlopen()
accepts as its first argument, a .so shared library, a .o object file or an executable ELF file?
Thanks.
linux shared-library dynamic-loading
linux shared-library dynamic-loading
edited 13 secs ago
asked 4 hours ago
Tim
24.2k67233423
24.2k67233423
Where is this strange text from?
â schily
4 hours ago
It looks like the author of that text does not really understand how dynamic loading works.
â schily
4 hours ago
@schily Thanks. I am wondering what a relocatable format means? Do an executable, .so shared library, .o object file all have a relocatable format?
â Tim
4 hours ago
2
It's unfortunate that someone has (presumably) violated the Copyright of the 2009 book by posting it online. "No part of this publication may be reproduced..." -- and apparently there are many other such files on that jufiles website. Is there any indication that the website has acquired "prior written consent" from the publishers?
â Jeff Schaller
4 hours ago
1
Perhaps, besides the written quote in question, a regular old reference to the book would do? Title, author, editon, date, ISBN?
â Jeff Schaller
3 hours ago
add a comment |Â
Where is this strange text from?
â schily
4 hours ago
It looks like the author of that text does not really understand how dynamic loading works.
â schily
4 hours ago
@schily Thanks. I am wondering what a relocatable format means? Do an executable, .so shared library, .o object file all have a relocatable format?
â Tim
4 hours ago
2
It's unfortunate that someone has (presumably) violated the Copyright of the 2009 book by posting it online. "No part of this publication may be reproduced..." -- and apparently there are many other such files on that jufiles website. Is there any indication that the website has acquired "prior written consent" from the publishers?
â Jeff Schaller
4 hours ago
1
Perhaps, besides the written quote in question, a regular old reference to the book would do? Title, author, editon, date, ISBN?
â Jeff Schaller
3 hours ago
Where is this strange text from?
â schily
4 hours ago
Where is this strange text from?
â schily
4 hours ago
It looks like the author of that text does not really understand how dynamic loading works.
â schily
4 hours ago
It looks like the author of that text does not really understand how dynamic loading works.
â schily
4 hours ago
@schily Thanks. I am wondering what a relocatable format means? Do an executable, .so shared library, .o object file all have a relocatable format?
â Tim
4 hours ago
@schily Thanks. I am wondering what a relocatable format means? Do an executable, .so shared library, .o object file all have a relocatable format?
â Tim
4 hours ago
2
2
It's unfortunate that someone has (presumably) violated the Copyright of the 2009 book by posting it online. "No part of this publication may be reproduced..." -- and apparently there are many other such files on that jufiles website. Is there any indication that the website has acquired "prior written consent" from the publishers?
â Jeff Schaller
4 hours ago
It's unfortunate that someone has (presumably) violated the Copyright of the 2009 book by posting it online. "No part of this publication may be reproduced..." -- and apparently there are many other such files on that jufiles website. Is there any indication that the website has acquired "prior written consent" from the publishers?
â Jeff Schaller
4 hours ago
1
1
Perhaps, besides the written quote in question, a regular old reference to the book would do? Title, author, editon, date, ISBN?
â Jeff Schaller
3 hours ago
Perhaps, besides the written quote in question, a regular old reference to the book would do? Title, author, editon, date, ISBN?
â Jeff Schaller
3 hours ago
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
A shared library does not really need to be relocatable. AT&T used non-relocatable shared libraries in SYSvr3 around 1987.
The method used by AT&T was based on fixed addresses in the shared lib and the shared lib was installed in system memory (usable by any process) by a special system tool at startup. The programs that used such libraries have been linked against the fixed addresses that were used at install time. This method is very limited as there is a need for a global administrator who defines load addresses for various libs.
The method that is used today is based on research at Sun Microsystems in 1987 and was published in December 1987.
It is based on the mmap()
facility in the kernel. Each program contains special startup code that maps the needed libraries that use relocatable code.
Each library contains a special table that contains offsets for various symbols in the library. Each program conains a table with function names and the binary does a Jump Subroutine to the table entry related to all functions needed.
That table entry contains a jump instruction to the runtime linker code and when it is used the first time, the runtime linker replaces that jump by a jump to the funtion in the shared library.
All this is handled by system software and not subject of the users program design.
BTW: the book claims that no program may become larger than the physical memory. This was true in the 1960s. IBM changed that in the early 1970s for their mainframes and BSD changed that in 1979 for UNIX with virtual memory management.
dlopen()
may be used to load dynamic libraries "manually" at run time and thus allows to make that depend on what happened before. A sound playing program may e.g. decide to use dlopen
to load a mp3
decoder after it discovers that a file argument refers to a sound file that uses mp3
encoding.
If you use dlopen
, linking to functions in the loaded shared library does not happen automatically. You need to use dlsym()
to get the address from the function name and then call the function by a pointer dereferencing.
You cannot dlopen
a .o
file as there is a need to have the _PROCEDURE_LINKAGE_TABLE_
and that is created by the special linking process that is needed to create a .so.
file.
The method used by Microsoft is derived from the manual method that is based on dlopen
. Microsoft however automatically creates code that works the way you do manually with dlopen
. The related code is inside the static library with the same name as the so called dll
. This static library is linked statically to the program and contains the trmapolin code that loads the library, retrives the function address and then calls the function pointer.
The Microsoft compiler always creates relocatable code, so even fully static libraries compiled with that compiler use relocatable code.
The claim that a routine is not loaded until referenced is wrong in the general case, it only applies to the dlopen
case.
Libraries managed by the ELF runtime system may be listed via
ldd
,
libraries managed manally bydlopen
cannot be listed since their
names may be a result of run time string processing.
Thanks. "the book claims that no program may become larger than the physical memory." It doesn't, see ch9 virtual memory. Let's try to understand the textbook.
â Tim
4 hours ago
Your quoted text contains: "The size of a process has thus been limited to the size of physical memory."
â schily
3 hours ago
That is in Ch8 which discusses memory management without virtual memory system.
â Tim
3 hours ago
OK, but this was not part of your quote.
â schily
3 hours ago
I think the quote in my post for dynamic loading still applies in virtual memory system.
â Tim
3 hours ago
 |Â
show 11 more comments
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
A shared library does not really need to be relocatable. AT&T used non-relocatable shared libraries in SYSvr3 around 1987.
The method used by AT&T was based on fixed addresses in the shared lib and the shared lib was installed in system memory (usable by any process) by a special system tool at startup. The programs that used such libraries have been linked against the fixed addresses that were used at install time. This method is very limited as there is a need for a global administrator who defines load addresses for various libs.
The method that is used today is based on research at Sun Microsystems in 1987 and was published in December 1987.
It is based on the mmap()
facility in the kernel. Each program contains special startup code that maps the needed libraries that use relocatable code.
Each library contains a special table that contains offsets for various symbols in the library. Each program conains a table with function names and the binary does a Jump Subroutine to the table entry related to all functions needed.
That table entry contains a jump instruction to the runtime linker code and when it is used the first time, the runtime linker replaces that jump by a jump to the funtion in the shared library.
All this is handled by system software and not subject of the users program design.
BTW: the book claims that no program may become larger than the physical memory. This was true in the 1960s. IBM changed that in the early 1970s for their mainframes and BSD changed that in 1979 for UNIX with virtual memory management.
dlopen()
may be used to load dynamic libraries "manually" at run time and thus allows to make that depend on what happened before. A sound playing program may e.g. decide to use dlopen
to load a mp3
decoder after it discovers that a file argument refers to a sound file that uses mp3
encoding.
If you use dlopen
, linking to functions in the loaded shared library does not happen automatically. You need to use dlsym()
to get the address from the function name and then call the function by a pointer dereferencing.
You cannot dlopen
a .o
file as there is a need to have the _PROCEDURE_LINKAGE_TABLE_
and that is created by the special linking process that is needed to create a .so.
file.
The method used by Microsoft is derived from the manual method that is based on dlopen
. Microsoft however automatically creates code that works the way you do manually with dlopen
. The related code is inside the static library with the same name as the so called dll
. This static library is linked statically to the program and contains the trmapolin code that loads the library, retrives the function address and then calls the function pointer.
The Microsoft compiler always creates relocatable code, so even fully static libraries compiled with that compiler use relocatable code.
The claim that a routine is not loaded until referenced is wrong in the general case, it only applies to the dlopen
case.
Libraries managed by the ELF runtime system may be listed via
ldd
,
libraries managed manally bydlopen
cannot be listed since their
names may be a result of run time string processing.
Thanks. "the book claims that no program may become larger than the physical memory." It doesn't, see ch9 virtual memory. Let's try to understand the textbook.
â Tim
4 hours ago
Your quoted text contains: "The size of a process has thus been limited to the size of physical memory."
â schily
3 hours ago
That is in Ch8 which discusses memory management without virtual memory system.
â Tim
3 hours ago
OK, but this was not part of your quote.
â schily
3 hours ago
I think the quote in my post for dynamic loading still applies in virtual memory system.
â Tim
3 hours ago
 |Â
show 11 more comments
up vote
0
down vote
A shared library does not really need to be relocatable. AT&T used non-relocatable shared libraries in SYSvr3 around 1987.
The method used by AT&T was based on fixed addresses in the shared lib and the shared lib was installed in system memory (usable by any process) by a special system tool at startup. The programs that used such libraries have been linked against the fixed addresses that were used at install time. This method is very limited as there is a need for a global administrator who defines load addresses for various libs.
The method that is used today is based on research at Sun Microsystems in 1987 and was published in December 1987.
It is based on the mmap()
facility in the kernel. Each program contains special startup code that maps the needed libraries that use relocatable code.
Each library contains a special table that contains offsets for various symbols in the library. Each program conains a table with function names and the binary does a Jump Subroutine to the table entry related to all functions needed.
That table entry contains a jump instruction to the runtime linker code and when it is used the first time, the runtime linker replaces that jump by a jump to the funtion in the shared library.
All this is handled by system software and not subject of the users program design.
BTW: the book claims that no program may become larger than the physical memory. This was true in the 1960s. IBM changed that in the early 1970s for their mainframes and BSD changed that in 1979 for UNIX with virtual memory management.
dlopen()
may be used to load dynamic libraries "manually" at run time and thus allows to make that depend on what happened before. A sound playing program may e.g. decide to use dlopen
to load a mp3
decoder after it discovers that a file argument refers to a sound file that uses mp3
encoding.
If you use dlopen
, linking to functions in the loaded shared library does not happen automatically. You need to use dlsym()
to get the address from the function name and then call the function by a pointer dereferencing.
You cannot dlopen
a .o
file as there is a need to have the _PROCEDURE_LINKAGE_TABLE_
and that is created by the special linking process that is needed to create a .so.
file.
The method used by Microsoft is derived from the manual method that is based on dlopen
. Microsoft however automatically creates code that works the way you do manually with dlopen
. The related code is inside the static library with the same name as the so called dll
. This static library is linked statically to the program and contains the trmapolin code that loads the library, retrives the function address and then calls the function pointer.
The Microsoft compiler always creates relocatable code, so even fully static libraries compiled with that compiler use relocatable code.
The claim that a routine is not loaded until referenced is wrong in the general case, it only applies to the dlopen
case.
Libraries managed by the ELF runtime system may be listed via
ldd
,
libraries managed manally bydlopen
cannot be listed since their
names may be a result of run time string processing.
Thanks. "the book claims that no program may become larger than the physical memory." It doesn't, see ch9 virtual memory. Let's try to understand the textbook.
â Tim
4 hours ago
Your quoted text contains: "The size of a process has thus been limited to the size of physical memory."
â schily
3 hours ago
That is in Ch8 which discusses memory management without virtual memory system.
â Tim
3 hours ago
OK, but this was not part of your quote.
â schily
3 hours ago
I think the quote in my post for dynamic loading still applies in virtual memory system.
â Tim
3 hours ago
 |Â
show 11 more comments
up vote
0
down vote
up vote
0
down vote
A shared library does not really need to be relocatable. AT&T used non-relocatable shared libraries in SYSvr3 around 1987.
The method used by AT&T was based on fixed addresses in the shared lib and the shared lib was installed in system memory (usable by any process) by a special system tool at startup. The programs that used such libraries have been linked against the fixed addresses that were used at install time. This method is very limited as there is a need for a global administrator who defines load addresses for various libs.
The method that is used today is based on research at Sun Microsystems in 1987 and was published in December 1987.
It is based on the mmap()
facility in the kernel. Each program contains special startup code that maps the needed libraries that use relocatable code.
Each library contains a special table that contains offsets for various symbols in the library. Each program conains a table with function names and the binary does a Jump Subroutine to the table entry related to all functions needed.
That table entry contains a jump instruction to the runtime linker code and when it is used the first time, the runtime linker replaces that jump by a jump to the funtion in the shared library.
All this is handled by system software and not subject of the users program design.
BTW: the book claims that no program may become larger than the physical memory. This was true in the 1960s. IBM changed that in the early 1970s for their mainframes and BSD changed that in 1979 for UNIX with virtual memory management.
dlopen()
may be used to load dynamic libraries "manually" at run time and thus allows to make that depend on what happened before. A sound playing program may e.g. decide to use dlopen
to load a mp3
decoder after it discovers that a file argument refers to a sound file that uses mp3
encoding.
If you use dlopen
, linking to functions in the loaded shared library does not happen automatically. You need to use dlsym()
to get the address from the function name and then call the function by a pointer dereferencing.
You cannot dlopen
a .o
file as there is a need to have the _PROCEDURE_LINKAGE_TABLE_
and that is created by the special linking process that is needed to create a .so.
file.
The method used by Microsoft is derived from the manual method that is based on dlopen
. Microsoft however automatically creates code that works the way you do manually with dlopen
. The related code is inside the static library with the same name as the so called dll
. This static library is linked statically to the program and contains the trmapolin code that loads the library, retrives the function address and then calls the function pointer.
The Microsoft compiler always creates relocatable code, so even fully static libraries compiled with that compiler use relocatable code.
The claim that a routine is not loaded until referenced is wrong in the general case, it only applies to the dlopen
case.
Libraries managed by the ELF runtime system may be listed via
ldd
,
libraries managed manally bydlopen
cannot be listed since their
names may be a result of run time string processing.
A shared library does not really need to be relocatable. AT&T used non-relocatable shared libraries in SYSvr3 around 1987.
The method used by AT&T was based on fixed addresses in the shared lib and the shared lib was installed in system memory (usable by any process) by a special system tool at startup. The programs that used such libraries have been linked against the fixed addresses that were used at install time. This method is very limited as there is a need for a global administrator who defines load addresses for various libs.
The method that is used today is based on research at Sun Microsystems in 1987 and was published in December 1987.
It is based on the mmap()
facility in the kernel. Each program contains special startup code that maps the needed libraries that use relocatable code.
Each library contains a special table that contains offsets for various symbols in the library. Each program conains a table with function names and the binary does a Jump Subroutine to the table entry related to all functions needed.
That table entry contains a jump instruction to the runtime linker code and when it is used the first time, the runtime linker replaces that jump by a jump to the funtion in the shared library.
All this is handled by system software and not subject of the users program design.
BTW: the book claims that no program may become larger than the physical memory. This was true in the 1960s. IBM changed that in the early 1970s for their mainframes and BSD changed that in 1979 for UNIX with virtual memory management.
dlopen()
may be used to load dynamic libraries "manually" at run time and thus allows to make that depend on what happened before. A sound playing program may e.g. decide to use dlopen
to load a mp3
decoder after it discovers that a file argument refers to a sound file that uses mp3
encoding.
If you use dlopen
, linking to functions in the loaded shared library does not happen automatically. You need to use dlsym()
to get the address from the function name and then call the function by a pointer dereferencing.
You cannot dlopen
a .o
file as there is a need to have the _PROCEDURE_LINKAGE_TABLE_
and that is created by the special linking process that is needed to create a .so.
file.
The method used by Microsoft is derived from the manual method that is based on dlopen
. Microsoft however automatically creates code that works the way you do manually with dlopen
. The related code is inside the static library with the same name as the so called dll
. This static library is linked statically to the program and contains the trmapolin code that loads the library, retrives the function address and then calls the function pointer.
The Microsoft compiler always creates relocatable code, so even fully static libraries compiled with that compiler use relocatable code.
The claim that a routine is not loaded until referenced is wrong in the general case, it only applies to the dlopen
case.
Libraries managed by the ELF runtime system may be listed via
ldd
,
libraries managed manally bydlopen
cannot be listed since their
names may be a result of run time string processing.
edited 3 hours ago
answered 4 hours ago
schily
9,96531638
9,96531638
Thanks. "the book claims that no program may become larger than the physical memory." It doesn't, see ch9 virtual memory. Let's try to understand the textbook.
â Tim
4 hours ago
Your quoted text contains: "The size of a process has thus been limited to the size of physical memory."
â schily
3 hours ago
That is in Ch8 which discusses memory management without virtual memory system.
â Tim
3 hours ago
OK, but this was not part of your quote.
â schily
3 hours ago
I think the quote in my post for dynamic loading still applies in virtual memory system.
â Tim
3 hours ago
 |Â
show 11 more comments
Thanks. "the book claims that no program may become larger than the physical memory." It doesn't, see ch9 virtual memory. Let's try to understand the textbook.
â Tim
4 hours ago
Your quoted text contains: "The size of a process has thus been limited to the size of physical memory."
â schily
3 hours ago
That is in Ch8 which discusses memory management without virtual memory system.
â Tim
3 hours ago
OK, but this was not part of your quote.
â schily
3 hours ago
I think the quote in my post for dynamic loading still applies in virtual memory system.
â Tim
3 hours ago
Thanks. "the book claims that no program may become larger than the physical memory." It doesn't, see ch9 virtual memory. Let's try to understand the textbook.
â Tim
4 hours ago
Thanks. "the book claims that no program may become larger than the physical memory." It doesn't, see ch9 virtual memory. Let's try to understand the textbook.
â Tim
4 hours ago
Your quoted text contains: "The size of a process has thus been limited to the size of physical memory."
â schily
3 hours ago
Your quoted text contains: "The size of a process has thus been limited to the size of physical memory."
â schily
3 hours ago
That is in Ch8 which discusses memory management without virtual memory system.
â Tim
3 hours ago
That is in Ch8 which discusses memory management without virtual memory system.
â Tim
3 hours ago
OK, but this was not part of your quote.
â schily
3 hours ago
OK, but this was not part of your quote.
â schily
3 hours ago
I think the quote in my post for dynamic loading still applies in virtual memory system.
â Tim
3 hours ago
I think the quote in my post for dynamic loading still applies in virtual memory system.
â Tim
3 hours ago
 |Â
show 11 more comments
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f476083%2fwhat-kinds-of-files-can-be-dynamically-loaded%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Where is this strange text from?
â schily
4 hours ago
It looks like the author of that text does not really understand how dynamic loading works.
â schily
4 hours ago
@schily Thanks. I am wondering what a relocatable format means? Do an executable, .so shared library, .o object file all have a relocatable format?
â Tim
4 hours ago
2
It's unfortunate that someone has (presumably) violated the Copyright of the 2009 book by posting it online. "No part of this publication may be reproduced..." -- and apparently there are many other such files on that jufiles website. Is there any indication that the website has acquired "prior written consent" from the publishers?
â Jeff Schaller
4 hours ago
1
Perhaps, besides the written quote in question, a regular old reference to the book would do? Title, author, editon, date, ISBN?
â Jeff Schaller
3 hours ago