lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory libs

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:25:00 -05:00
parent a4964ba92d
commit 07129c3397
135 changed files with 3543 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

139
libs/jumplibs/building.txt Normal file
View File

@@ -0,0 +1,139 @@
It could be expected:
> Thanks a lot for your effort. I have a favor to ask. How do you make
> the jump libs? (or even the classic shared libs for that matter).
I'm totally ignorant on building non-jumped shared libs. I've done that
in the past, but the procedure has undergone major changes.
I've had some help from David Engel myself.
A (too) short description:
-1) This document assumes that you know what a jump-lib is, and how it
(basically) works.
0) Get one of my libs (package librl01.TZ comes to mind), and clean
out the source directories. Also get the shlib package from HLU,
which has good examples for very complex libraries like libc and
libX11. Mine are much simpler, and my adapted scripts are not
able to cope with cross-compiling and other goodies.
1) Create the new soucre dir, build the normal lib, and run:
nm libXXX.a | grep \ D\ | awk '{print $3}' > global.data
nm libXXX.a | grep \ T\ | awk '{print $3}' |\
sed 's/^_//' | sort >global.text
(note that I'm thinking while I'm typing).
2) If the global.data file is not empty then you basically have a problem,
because data cannot be accessed by jumptables: it has to stay in exactly
the same position over the years. All the data variables like:
int global_var = 3;
in the code have to be replaced by something like:
#ifndef jump
int global_var = 3;
#else
extern in global_var;
#endif
and you have to create an extra C file (I called it 00_DATA.c to
make it different from all the others) in which you collect all the
global data. In this example the following line is added:
int global_var = 3;
You could embed the whole 00_DATA.c file in '#ifdef jump' '#endif'.
If there any 'struct's in the global data, it is wise to put in
some dummy variables with HaRd_TO_gUeSS names, to allow for growth
in later versions.
I don't have any experience with data that is in the BSS section.
Basically it is not possible to have a 'jump' BSS section, so if
variables from the BSS section are needed globally, they must
be initialised, and therefore moved to the DATA section.
If some of the detected 'global data' will not be needed from
outside the library (so: from your program) then you don't need
to move it to 00_DATA.c, but YOU BETTER BE SURE because it could
break backward compatibility if you prove to be wrong.
3) Ok, now adapt the Makefile and recompile the library, specifying
'-Djump'. Don't forget to add in the 00_DATA.o in the library.
4) Copy the library and the 00_DATA.o file up one level. I did this in
the Makefile that is located there, so you can probably change
the Makefile to do it for you.
5) cd to the jump directory and 'rm lib*' there. There is also one
subdirectory, which has the name of the library (eg c, for libc;
rl, for readline). If you're planning to be compatible with the
minix filesystem (I for instance still only run that), you'll
have to choose a name not exceeding 3 characters. Remove the
directory from the package you got, and create your own new one.
6) Now modify the Makefile in the 'jump' directory, to let it
know where it is, and specify the lib-dependent stuff at the top.
In my 'f2c' and 'gr' libs, I had to add in a kludge, this is in
the target 'xtra'. If you're using one of these as your example,
you should get rid of the 'xtra' target and its references too.
Mail hlu@eecs.wsu.edu (as long as this address can be reached,
otherwise try david@ods.com) to get address space for your
lib. If you're just experimenting this is not necessary, but
anyway please make sure that your lib doesn't collide with other
shared libs present on your system.
Modify the SYSTEM LIBRARIES field to contain all the libs your
lib will depend on.
7) cd into your libname directory below jump (let's call it XX for
now), and copy the 'text.global' file here that you've built
earlier. Call it libXX.jump1. Look at this file: it should contain
the names of all functions that are callable from the outside.
If you ever want to rebuild your library YOU MAY NEVER CHANGE THIS
FILE AGAIN, EXCEPT FOR ADDING NAMES AT THE END!!!!. that is the
principle of the jump lib: everything stays exactly at the same
place. Only if you bump your MAJOR version number in the Makefile,
you may completely replace this file: in that case you completely
lose your compatibility with earlier versions.
8) cd up again to the 'jump' directory. type 'Make' and hope for the
best. If you (or I) forgot something or did something wrong, the
scripts will warn you. If you can't find out what goes wrong, add
'set -x' to the script that fails, and watch it go by.
9) If your lib depends on anything else than libc, and you're afraid
that the other lib will sometimes not be linked in, please get my
'libgr' package, and see how I solved this for the Math lib: look
for math.c. The problem here is that some programs may need
'libtiff' and not need any math function, while 'libtiff' itself
needs the math lib. With help of 'math.c' it is insured that any
program needing the libtiff.a part of the lib is always linked
with the jump table math lib.
10) If this is a re-build of an old jumplib: now check if all global
data addresses have stayed the same. Use 'nm' to do this.
If it is the first time:
You can also run nm on all the stub-libs, then recompile your
lib with another optimisation level (-O6 = -O2 !!), rebuild the
jumplib and see if some addresses in the stublibs change. That
could indicate that you forgot something, and will lose
compatibility at the next upgrade. Take corrective action
immediately.
11) If you have a function that does a call-back to your program at
a known entrypoint, you have another problem. Please get my 'libf2c'
package and study my kludge: It concerns the file 'main.c', which
calls the fortran __MAIN__ program.
Please if you find out errors or omissions in this document, let me
know! You can also ask me questions: I'll see if I can answer them.
Rob Hooft (hooft@chem.ruu.nl)