[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Native GCC built
On 20/11/2013 03:46, Miro Kropáček wrote:
Tricks like trying to achieve ".;@m68000" don't make sense because gcc
then tries to create a /subdirectory "."/ and fails.
Ok, that was just an idea.
Anyway, requiring to use *specific* options to build *default* libraries
was somehow an insane idea.
Now, the <prefix>/m68000 solution. Doesn't make sense either because
then we'd end up in correct installation, true but with duplicated gcc
libraries.
My idea was to put 68000 libraries in <prefix>/m68000 *only*, and leave
<prefix> empty, in any case. So everything will be stored in the proper
subdirectory tree, identical on every host.
I mention this solution because when I worked on GCC in early days, I
somehow got that situation by mistake.
While this is the cleanest solution (one subdir for each target), this
is not the standard one. Definitely, the real solution is to mimic what
has been done for i386/x64, since the situation is very close. There are
still problems inherent to the multilib design, I will answer to Alan's
message.
IMO, the only correct solution to this problem is to do it as everywhere
else:
I agree.
<prefix> for the current host build (whatever it is)
<prefix>/<subdir> for foreign multilibs
But that means different library binary packages for different build hosts.
For example, the mintlib binary package will have:
- for 68000 gcc, 68000 libraries in /usr/lib and ColdFire libraries in
/usr/lib/m5475
- for ColdFire gcc, ColdFire libraries in /usr/lib and 68000 libraries
in /usr/lib/m68000
In other words, if someone provides a binary package for a library, he
will have to provide different packages for native 68000 gcc, native
ColdFire gcc, Ubuntu cross-compiler, Cygwin cross-compiler... Every
library binary package will contain exactly the same binaries, but in
different directories.
I don't think this is a problem, since each distribution provides its
own set of pre-compiled libraries: SpareMiNT for 68000, Cygwin
cross-tools, future Gentoo for ColdFire, etc.
1. Three different branches how to create multilib targets. Sounds hard
but it is not. For example, x64 linux does following:
MULTILIB_OPTIONS = m64/m32
MULTILIB_DIRNAMES = 64 32
MULTILIB_OSDIRNAMES = ../lib64$(call if_multiarch,:x86_64-linux-gnu) \
$(if $(wildcard $(shell echo
$(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call
if_multiarch,:i386-linux-gnu)
i.e. it dynamically generates multilib directories based on detected
host/target.
This is definitely the example to follow.
2. Remove any dependency on defined multilib structure from mintlib and
lib projects, leaving only a CFLAGS friendly option of one installation
(similar what Alan wants to achieve with the kernel build).
Totally true, the libs makefiles don't have to mess with the multilibs.
It's the responsibility of the maintainer to tweak CFLAGS when he wants
to build the libraries for the other architectures. This is exactly what
happens now when compiling GNU/Linux libraries for MiNT.
When I think about it, I don't know why we insisted to have the
stable multilib structure so much, pml, mintlib and
gemlib/cflib/gemma are the only projects which depend on this,
Because people wanted "a single binary package for everyone", which is a
broken idea by design.
--
Vincent Rivière