Source code for TinyCore and CorePlus

[Paulo]

Hi

In an effort to better understand Linux, I have been doing some static and dynamic linking and looking at the startup times versus executable sizes.
I also use dlopen ("/path/to/some/lib.so", RTLD_LAZY) to call/use functions in libs.
To then use the actual functions, I call them with dlsym(handle, "TheFunction") however I will need to know what these functions
are called, what parameters and variable types they use.
I'm assuming the only way to get these is to look at the source, hence my question, where can one get the source for TinyCore and CorePlus?

Thanks.

[gerald_clark]

Source of what?  The kernel source is nothing special.  Most of the core init functions are simple shell scripts which you can view from any core installation.

[Paulo]

Hi gerald_clark

OK, I thought perhaps the kernel had been recompiled with some tweaks and/or extra boot options.

[tinypoodle]

config and patches are in repo, start from Download page.

[gerald_clark]

The startup code and extra boot code are in /etc/init.d/tc-config.

[Paulo]

Thank you.

[Rich]

Hi Paulo
If you don't mind my asking, why are you using  dlopen? I've never used it myself, so I did some quick reading
on the function. From what I read, that function is used to allow you to check for the availability of libraries and
check them for functions and objects to add additional functions to a program. An example of that might be an
audio program that makes certain controls available depending on which audio libraries it finds.
Unless you have a real need to implement  this type of capability, I think you might be better off linking dynamically
and including any extra libraries as dependencies.

[Paulo]

Hi Rich

You are 100% correct in what you say about dynamic linking however I was just trying to learn about both ways
in which to compile binary executables and their pros and cons.

The big advantage of dynamic linking is the resulting smaller file size, however static linking also has an advantage of
reducing the dependency issues as everything required is "built-in".

Using strip helps in reducing the binaries size so does passing the parameter --as-needed to ld via gcc.

[Rich]

Hi /optional
I guess the point I was really trying to make is that you don't need to use  dlopen  just because you are
linking dynamically.

[Paulo]

Hi Rich

OK, I just thought it was the easiest way and it seems to work with both static and dynamic.
What alternative would you recommend as coming from the Windows environment this is all new to me and quite confusing at times.

Basically what I'm trying to achieve is minimizing the dependency headaches between the three distros I use, namely TC, Puppy and Mint.
So if I compile something say in Puppy (CLI apps), it will pretty much work on all three.
Static linking seems to work best for this.

[Rich]

Hi Paulo
If you are just compiling CLI apps, and not linking to any external development packages, you should have no
dependencies except for the standard C libraries, which should always be installed as part of the OS.
Compile one of your programs dynamically and copy it to your other two systems. Then run:

Code: [Select]

ldd ./ProgramNameThis will show you its dependencies and if any could not be found. If your machines all have the same version
of libc (and maybe libm) and all you use are standard C library calls, you should be OK.

[Paulo]

Great, thanks Rich.