Creating Shared Object libraries

[Velko]

Hello!

To compile userspace executables I am using full GCC cross compiler - the usual Binutils-GCC-Newlib combo, basically OS Specific Toolchain with few modifications. It works fine, compiles and links static executables without any issues.

I am going to experiment with Shared Object libraries. However, I have issues while producing one using my cross-toolchain.

Code: Select all

x86_64-pc-myos-gcc -c -fPIC foo.c -o foo.o
x86_64-pc-myos-gcc -shared foo.o -o libfoo.so

Second command does not work as expected. I get error:

x86_64-pc-myos-gcc: error: unrecognized command line option '-shared'

I configured Binutils & GCC using commands/switches:

Code: Select all

../binutils-src/configure --prefix=/usr/local/cross --disable-nls --disable-werror --target=x86_64-pc-myos --enable-64-bit-bfd --with-sysroot=/usr/local/cross/x86_64-pc-myos --enable-shared
../gcc-src/configure --target=x86_64-pc-myos --prefix=/usr/local/cross --disable-nls --enable-languages=c,c++ --with-newlib --with-sysroot=/usr/local/cross/x86_64-pc-myos --enable-shared

Obviously, I am missing something Please advise.

[iansjack]

There is an option

--enable-host-shared

in the configure options for gcc. Try building the cross-compiler with that option specified.

[Velko]

--enable-host-shared

in the configure options for gcc. Try building the cross-compiler with that option specified.

Rebuilt the toolchain. Problem remains

Isn't --enable-host-shared affecting how the GCC itself is built, not what it will generate for target platform?

If I understand GCC Configuration correctly, I shouldn't even need to specify --enable-shared

... shared libraries are enabled by default on all platforms that support shared libraries.

It looks like GCC config tools assumes that shared libraries are not supported on my OS. (Well, technically that is true for now ).

I tried to use LD directly:

Code: Select all

x86_64-pc-myos-ld -shared foo.o -o libfoo.so

It works and the resulting file looks like Shared Object file. I assume that my Binutils are fine and the problem is within GCC.

Unfortunately, most build systems/scripts uses GCC to link .so files.

[iansjack]

Yes, I suspect you are correct.

I remember that I had to use separate compile and link stages to produce shared libraries. Using gcc directly resulted in the ldloader being linked in to the shared library when I wanted to handle loading myself.

[Velko]

It looks like I've stumbled on an uncharted territory. Here is what I have found out so far.

To enable shared library support, I had to adjust gcc/config/myos.h file in GCC sources.

Code: Select all

#undef LIB_SPEC
#define LIB_SPEC "%{!shared: --start-group -lc -lmyos --end-group}"

#undef STARTFILE_SPEC
#define STARTFILE_SPEC "%{!shared: crt0.o%s} crti.o%s %{!shared: crtbegin.o%s} %{shared: crtbeginS.o%s}"

#undef ENDFILE_SPEC
#define ENDFILE_SPEC "%{!shared: crtend.o%s} %{shared: crtendS.o%s} crtn.o%s"

#define DYNAMIC_LINKER "/lib/loader.so"

#undef  LINK_SPEC
#define LINK_SPEC  "%{shared:-shared} %{!shared: %{static:-static} %{!static: -dynamic-linker " DYNAMIC_LINKER "}}"

Basically one needs to specify conditional expressions for several link variables, depending on link mode.

I's probably a good idea to enable crtbeginS.o and crtendS.o in libgcc/config.host, while at it.

Code: Select all

x86_64-*-myos*)
	extra_parts="$extra_parts crtbegin.o crtend.o crtbeginS.o crtendS.o"
	tmake_file="$tmake_file i386/t-crtstuff t-crtstuff-pic t-libgcc-pic"
	;;

Now only to figure out how to build shared versions of libstdc++v3 and Newlib's Libc.