Build shared libstdc++ on cross gcc

[marcxDotdev]

Hi everyone, I'm new to this forum, but I'm still developing my operating system since 4 years (it's name is MeetiX OS).
I'm adding to my operating system the dynamic linker to support shared libraries but i noticed that the cross building of the GCC (v4.9.1) doesn't creates the libstdc++.so.
On the gcc's configure i added the parameters "--enable-shared" and "--enable-host-shared" and on the config file that patch the gcc i added the support for dynamic executables

Code: Select all

diff -Nur gcc-4.9.1/gcc/config/mx.h gcc-4.9.1-mx/gcc/config/mx.h
--- gcc-4.9.1/gcc/config/mx.h	1970-01-01 01:00:00.000000000 +0100
+++ gcc-4.9.1-mx/gcc/config/mx.h	2017-05-22 21:57:42.000000000 +0200
@@ -0,0 +1,32 @@
+// built-in defines
+#undef TARGET_OS_CPP_BUILTINS
+#define TARGET_OS_CPP_BUILTINS()		\
+do {									\
+	builtin_define_std ("MeetiX");		\
+	builtin_define_std ("unix");		\
+	builtin_assert ("system=mx");	\
+	builtin_assert ("system=unix");		\
+} while(0);
+
+// for MeetiX-specific changes on GCC
+#undef	TARGET_MEETIX
+#define TARGET_MEETIX 1
+
+// don't automatically add extern "C" { } around header files
+#undef	NO_IMPLICIT_EXTERN_C
+#define	NO_IMPLICIT_EXTERN_C 1
+
+// define the default library specifications
+#undef	LIB_SPEC
+#define LIB_SPEC "%{!shared:--start-group -lapi -lc --end-group}"
+
+// start and end files
+#undef STARTFILE_SPEC
+#define STARTFILE_SPEC "%{!shared: %{!pg:crt0.o%s}} crti.o%s %{!shared:crtbegin.o%s}"
+
+#undef ENDFILE_SPEC
+#define ENDFILE_SPEC "%{!shared:crtend.o%s} crtn.o%s"
+
+// specify the links types
+#undef LINK_SPEC
+#define LINK_SPEC "%{shared:-shared} %{static:-static} %{!shared: %{!static: %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker /lib/ld.so}}}"
+
+// modify location of the start files
+#undef	STANDARD_STARTFILE_PREFIX
+#define	STANDARD_STARTFILE_PREFIX "/lib/"

but this seems insufficient...
From what I read in another thread the problem is in libtool, that doesn't recognize the cross target, but I didn't find anything that could help me to solve it.

[Korona]

Yes, libtool is the problem.

GCC bundles libtool in ibtool.m4. You need to patch it like this (click me!) or more specifically like this (click again!). Oh god, opening that file reminded me that I called my multilib directories fizz and buzz for debugging purposes and never changed that back to the real names .

Building a shared libgcc is a bit different as that requires you to modify the tmake_file variable and add all those t-slibgcc t-slibgcc-gld t-slibgcc-elf-ver t-libgcc-pic options.

By the way, --enable-shared is the default once you configure libtool so that it can build shared libraries (and is overridden if libtool doesn't know how to do it), so you should never need that.

[marcxDotdev]

Thank you Korona.
Now libtool tries to create .so, but the link process fails with :

Code: Select all

MeetiX-OS/toolchain/build/build-gcc/i686-pc-mx/libstdc++-v3/src/c++11/../../../../../gcc-4.9.1/libstdc++-v3/src/c++11/system_error.cc:65: undefined reference to `__dso_handle'
MeetiX-OS/toolchain/MeetiXOSProject/i686-pc-mx/bin/ld: ../src/c++11/.libs/libc++11convenience.a(system_error.o): relocation R_386_GOTOFF against undefined hidden symbol `__dso_handle' can not be used when making a shared object
MeetiX-OS/toolchain/MeetiXOSProject/i686-pc-mx/bin/ld: final link failed: Bad value

From what I have been able to see by analyzing a bit the sources of the library __dso_handle is a symbol that inserts the compiler, but I'm probably missing some configuration parameters, it is not possible that there is such a rough error inside the source

[Korona]

Yes, __dso_handle is a DSO-local variable. Its address is used at some points where a unique per-DSO identifier is required (for example, for __cxa_atexit).

__dso_handle should be defined by libgcc. I think it is in crtbegin.o (crtstuff.c is quite messy). I think you need to link against crtbeginS.o when creating a shared object, just like my GCC patch does (its in the STARTFILE_SPEC/ENDFILE_SPEC).

[marcxDotdev]

Mmmh, Do I have to compile libgcc as shared too?

[Korona]

I'm not sure about that but I do think so. GCC internally uses libgcc to perform various operations that it cannot do inline. If libgcc is compiled with -fPIC, it will not correctly link to shared objects.

[marcxDotdev]

I think I should try to create libgcc shared library...
How do I change the libgcc library to create a shared library? You said I should add some variables. Where should I add and what value should they have?

[Korona]

You can just look at my patch to figure that out. The relevant variable is the tmake_file variable which is defined in config.host. The relevant entries are the slibgcc* ones. Appending those entries to the variable tells the build system include makefiles from the libgcc/config directory that in turn build a shared libgcc.

[marcxDotdev]

Ok, now also libgcc creates the shared lib (but only that, I would also need static for my kernel ...), but the undefined reference to '__dso_handle' has remained.
I modified my patch with:

Code: Select all

diff -Nur gcc-4.9.1/libgcc/config.host gcc-4.9.1-mx/libgcc/config.host
--- gcc-4.9.1/libgcc/config.host	2014-03-27 16:40:31.000000000 +0100
+++ gcc-4.9.1-mx/libgcc/config.host	2017-11-17 16:49:50.942408261 +0100
@@ -314,6 +314,16 @@
 esac
 
 case ${host} in
+i[34567]86-*-mx*)
+	extra_parts="$extra_parts crtbegin.o crtend.o"
+	tmake_file="$tmake_file i386/t-crtstuff t-crtstuff-pic t-libgcc-pic"
+    tmake_file="$tmake_file t-slibgcc t-slibgcc-gld t-slibgcc-elf-ver t-libgcc-pic"
+	;;
+x86_64-*-mx*)
+	extra_parts="$extra_parts crtbegin.o crtend.o"
+	tmake_file="$tmake_file i386/t-crtstuff t-crtstuff-pic t-libgcc-pic"
+    tmake_file="$tmake_file t-slibgcc t-slibgcc-gld t-slibgcc-elf-ver t-libgcc-pic"
+	;;
 aarch64*-*-elf)
 	extra_parts="$extra_parts crtbegin.o crtend.o crti.o crtn.o"
 	tmake_file="${tmake_file} ${cpu_type}/t-aarch64"

If is possible i want to build shared and static lib too

[Korona]

The issue with __dso_handle should be fixed. Does objdump show whether crtbeginS.o contains __dso_handle? Did you include crtbeginS.o in your specs?

I build a separate compiler for my kernel, so I never bothered with a non-shared libgcc. I don't think using the same libgcc in the kernel and userspace will work in the long term anyway. For example, your kernel won't have pthread functions that libgcc will try to use when they are available. Once you want to build libstdc++ with std::thread support, this will be a problem. I had to do that long ago when I ported Google's protobuf library to my OS (which I now use to compose IPC messages).