linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Wuertele <dave-gnus@bfnet.com>
To: linux-c-programming@vger.kernel.org
Subject: Re: Why does linking a.so with b.so require execs to be linked both -la and -lb?
Date: Mon, 11 Aug 2003 17:10:24 -0700	[thread overview]
Message-ID: <m3vft320sv.fsf@bfnet.com> (raw)
In-Reply-To: tmml01xphg.ln2@thune.mrc-home.org

I asked my friend, who is a windows programmer, whether windows had
the same behavior.  He said absolutely not, and generated this test.
His test is even more interesting than mine.  It does the following:

1.  build two libraries libA and libB.  libA has one function that
    calls a function in libB.
2.  link libA and libB
3.  Erase libB
4.  link a program that uses A's function with libA --- WITHOUT HAVING
    ACCESS TO libB!

Why can't we do this on Linux?

Here's the windows demonstration:


C:\libtest>REM -- build.bat - build dynamic linking test 

C:\libtest>REM -- clean all output files and do a dir 

C:\libtest>erase libB.obj libB.dll libB.exp libB.lib  

C:\libtest>erase libA.obj libA.dll libA.exp libA.lib  

C:\libtest>erase prog.obj prog.exe 

C:\libtest>dir
 Volume in drive C is SilverBox
 Volume Serial Number is BCEE-2C23

 Directory of C:\libtest

08/11/2003  04:09 PM    <DIR>          .
08/11/2003  04:09 PM    <DIR>          ..
08/11/2003  04:07 PM             1,437 build.bat
08/11/2003  03:33 PM               159 libA.c
08/11/2003  03:33 PM                65 libA.h
08/11/2003  03:33 PM               112 libB.c
08/11/2003  03:33 PM                65 libB.h
08/11/2003  03:45 PM               202 prog.c
               6 File(s)          2,040 bytes
               2 Dir(s)  40,561,799,168 bytes free

C:\libtest>REM -- cat the contents of the files 

C:\libtest>type libA.h 
// FILE: libA.h

extern __declspec(dllimport) void libA_func();
C:\libtest>type libA.c 
// FILE: libA.c

#include "libB.h"

extern __declspec(dllexport) void libA_func()
{
    printf("libA_func() calling libB_func()\n");
    libB_func();
}
C:\libtest>type libB.h 
// FILE: libB.h

extern __declspec(dllimport) void libB_func();
C:\libtest>type libB.c 
// FILE: libB.c

extern __declspec(dllexport) void libB_func()
{
    printf("libB_func() executing()\n");
}
C:\libtest>type prog.c 
#include <stdio.h>
#include "libA.h"

int main(int argc, const char ** argv)
{
    printf("prog.exe calling libA_func()\n");
    libA_func();
    printf("prog.exe exiting\n");
    return 0;
}

C:\libtest>REM -- compile and link libB.c to libB.dll 

C:\libtest>cl -c libB.c 
libB.c

C:\libtest>link libB.obj /dll /out:"libB.dll" /implib:"libB.lib" 
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

   Creating library libB.lib and object libB.exp

C:\libtest>REM -- compile and link libA.c to libA.dll doing 

C:\libtest>REM -- the "-lB" equivalent 

C:\libtest>cl -c libA.c 
libA.c

C:\libtest>link libA.obj libB.lib /dll /out:"libA.dll" /implib:"libA.lib" 
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

   Creating library libA.lib and object libA.exp

C:\libtest>REM -- erase all of the libB output files to prove that linking 

C:\libtest>REM -- prog.c doesn't depend on libB. 

C:\libtest>erase libB.obj libB.dll libB.exp libB.lib  

C:\libtest>REM -- for good measure erase all of libA's output files except 

C:\libtest>REM -- the export library and the dll 

C:\libtest>erase  libA.obj libA.exp 

C:\libtest>REM -- do another dir so we can see what's in our directory now 

C:\libtest>dir
 Volume in drive C is SilverBox
 Volume Serial Number is BCEE-2C23

 Directory of C:\libtest

08/11/2003  04:09 PM    <DIR>          .
08/11/2003  04:09 PM    <DIR>          ..
08/11/2003  04:07 PM             1,437 build.bat
08/11/2003  03:33 PM               159 libA.c
08/11/2003  04:09 PM            45,056 libA.dll
08/11/2003  03:33 PM                65 libA.h
08/11/2003  04:09 PM             1,896 libA.lib
08/11/2003  03:33 PM               112 libB.c
08/11/2003  03:33 PM                65 libB.h
08/11/2003  03:45 PM               202 prog.c
               8 File(s)         48,992 bytes
               2 Dir(s)  40,561,750,016 bytes free

C:\libtest>REM -- compile prog.c into prog.exe 

C:\libtest>cl prog.c libA.lib 
prog.c
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/out:prog.exe 
prog.obj 
libA.lib 

C:\libtest>REM -- now that prog.exe has built, re-compile and link 

C:\libtest>REM -- libB so that prog.exe will run 

C:\libtest>cl -c libB.c 
libB.c

C:\libtest>link libB.obj /dll /out:"libB.dll" /implib:"libB.lib" 
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

   Creating library libB.lib and object libB.exp

C:\libtest>REM -- let's delete all output files again and do a dir 

C:\libtest>erase libB.obj libB.exp libB.lib  

C:\libtest>erase libA.obj libA.exp libA.lib  

C:\libtest>erase prog.obj 

C:\libtest>dir
 Volume in drive C is SilverBox
 Volume Serial Number is BCEE-2C23

 Directory of C:\libtest

08/11/2003  04:09 PM    <DIR>          .
08/11/2003  04:09 PM    <DIR>          ..
08/11/2003  04:07 PM             1,437 build.bat
08/11/2003  03:33 PM               159 libA.c
08/11/2003  04:09 PM            45,056 libA.dll
08/11/2003  03:33 PM                65 libA.h
08/11/2003  03:33 PM               112 libB.c
08/11/2003  04:09 PM            45,056 libB.dll
08/11/2003  03:33 PM                65 libB.h
08/11/2003  03:45 PM               202 prog.c
08/11/2003  04:09 PM            40,960 prog.exe
               9 File(s)        133,112 bytes
               2 Dir(s)  40,561,664,000 bytes free

C:\libtest>REM -- NOW FINALLY LET'S RUN THE PROGRAM! 

C:\libtest>prog.exe
prog.exe calling libA_func()
libA_func() calling libB_func()
libB_func() executing()
prog.exe exiting

C:\libtest>REM

C:\libtest>REM

C:\libtest>REM

C:\libtest>REM -- and let's type this file 

C:\libtest>type build.bat 
	REM -- build.bat - build dynamic linking test
	REM -- clean all output files and do a dir
erase libB.obj libB.dll libB.exp libB.lib 
erase libA.obj libA.dll libA.exp libA.lib 
erase prog.obj prog.exe
dir
	REM -- cat the contents of the files
type libA.h
type libA.c
type libB.h
type libB.c
type prog.c
	REM -- compile and link libB.c to libB.dll
cl -c libB.c
link libB.obj /dll /out:"libB.dll" /implib:"libB.lib"
	REM -- compile and link libA.c to libA.dll doing
	REM -- the "-lB" equivalent
cl -c libA.c
link libA.obj libB.lib /dll /out:"libA.dll" /implib:"libA.lib"
	REM -- erase all of the libB output files to prove that linking
	REM -- prog.c doesn't depend on libB.
erase libB.obj libB.dll libB.exp libB.lib 
	REM -- for good measure erase all of libA's output files except
	REM -- the export library and the dll
erase  libA.obj libA.exp
	REM -- do another dir so we can see what's in our directory now
dir
	REM -- compile prog.c into prog.exe
cl prog.c libA.lib
	REM -- now that prog.exe has built, re-compile and link
	REM -- libB so that prog.exe will run
cl -c libB.c
link libB.obj /dll /out:"libB.dll" /implib:"libB.lib"
	REM -- let's delete all output files again and do a dir
erase libB.obj libB.exp libB.lib 
erase libA.obj libA.exp libA.lib 
erase prog.obj
dir
	REM -- NOW FINALLY LET'S RUN THE PROGRAM!
prog.exe
	REM
	REM
	REM
	REM -- and let's type this file
type build.bat


  reply	other threads:[~2003-08-12  0:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-11 21:02 Why does linking a.so with b.so require execs to be linked both -la and -lb? David Wuertele
2003-08-11 23:50 ` Mike Castle
2003-08-12  0:10   ` David Wuertele [this message]
2003-08-12 13:49     ` Glynn Clements
2003-08-12 16:42       ` David Wuertele
2003-08-12 17:54         ` Glynn Clements
2003-08-12 19:12         ` Steven
2003-08-12  0:11   ` David Wuertele
2003-08-12 13:16 ` Glynn Clements

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3vft320sv.fsf@bfnet.com \
    --to=dave-gnus@bfnet.com \
    --cc=linux-c-programming@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).