home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8308 < prev    next >
Encoding:
Text File  |  1992-08-14  |  2.4 KB  |  52 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!usenet.coe.montana.edu!news.u.washington.edu!serval!phys1.physics.wsu.edu!hlu
  3. From: hlu@phys1.physics.wsu.edu (Hongjiu Lu)
  4. Subject: Re: shared libs - can everyone be happy with this?
  5. Message-ID: <1992Aug15.042420.18914@serval.net.wsu.edu>
  6. Sender: news@serval.net.wsu.edu (USENET News System)
  7. Organization: Washington State University
  8. References:  <1992Aug14.145754.29366@crd.ge.com>
  9. Date: Sat, 15 Aug 92 04:24:20 GMT
  10. Lines: 40
  11.  
  12. I am not sure if we are thinking the same thing. In up-coming gcc 2.2.2d,
  13. which I am planning to release this Sunday. There is only one version of the
  14. shared images, which is used by both jump table and good, old shared lib.
  15. If you use -jump in LDFLAGS, your executables are linked with jump table. The
  16. good, old shared lib is used by default, which uses the same shared images
  17. but bypasses the jump table.
  18.  
  19. -- 
  20. H.J.
  21. Gcc/libc maintainer for Linux.
  22. In article <1992Aug14.145754.29366@crd.ge.com>, davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
  23. |> 
  24. |>   I have an idea which I think might be a useful compromise between the
  25. |> "never recompile" and the "last ounce of performance" approaches.
  26. |> Unfortunately I can't find enough info on the GNU ld to know if it is
  27. |> feasible.
  28. |> 
  29. |>   What I propose is to have a module at the start of the shared library
  30. |> which is the jump table module. When the module is used it provides defs
  31. |> for each of the library functions by use of the jump table. The
  32. |> jumptbl() module would always be physically first in the library, so it
  33. |> would be "in the same place." So far this sounds like the original idea,
  34. |> right?
  35. |> 
  36. |>   If you didn't want to use the jump tables, you don't load the module
  37. |> and you get linked to the real routines directly in memory in the slib.
  38. |> The advantage of this is that you get all the benefits of the current
  39. |> slib implementation in terms of performance.
  40. |> 
  41. |>   This would allow
  42. |>   a. static link - runs anywhere
  43. |>   b. dynamic link - must relink for new slibs, but faster than -
  44. |>   c. jtablink - no need to relink for new libs, slightly slower than (b)
  45. |> 
  46. |> That would let the user decide what combination of size, portability and
  47. |> performance is best for each program, and that should make everyone happy.
  48. |> 
  49. |> -- 
  50. |> bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
  51. |>     I admit that when I was in school I wrote COBOL. But I didn't compile.
  52.