This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: GCC 4.0 Status Report (2005-02-03)
- From: Matt Rice <ratmice at yahoo dot com>
- To: gcc at gcc dot gnu dot org
- Cc: binutils at sources dot redhat dot com, libc-alpha at sources dot redhat dot com
- Date: Mon, 21 Feb 2005 11:45:24 -0800 (PST)
- Subject: Re: GCC 4.0 Status Report (2005-02-03)
sorry for the cross-posting but this proposal will
require some synergy between the three projects
> * Project Title
Frameworks for GNU Toolchain
> * Project Contributors
Matt Rice
> * Dependencies
Framework support in libc/bfd/binutils
> * Delivery Date
gcc portion is done, but blocked by the above.
> * Description
> What will you be doing?
[GCC]
Enabling the existing target framework code for darwin
for other platforms,
which adds a new header search mechanism for the
preprocessor
and passes options to ld analogous to -L and -l but
with a different library search mechanism
2 new options would be added to gcc, -F and -framework
-F is a combination of -I and -L which requires a
specific directory structure,
for example #include <foo/foo.h>
a simple comparison of the difference between the
header search mechanism
with -I/adir
/adir/foo/foo.h
with -F/adir
/adir/foo.framework/Headers/foo.h
-framework is not used by gcc other than to pass to
the linker, along which -F
which is also used for searching for library files,
[Binutils]
so when given the options "-F/adir -framework foo"
ld will look for /adir/foo.framework/foo
if "foo" is a symlink it will attempt to get the
realpath() of the file
the symlink should be inside the "foo.framework"
directory or a subdirectory of it.
for example "foo.framework/foo -> Versions/2/foo"
this creates a versioning method so that different
binaries can be linked to different versions
of a framework.
this will create an entry much like DT_NEEDED
to "foo.framework/Versions/2/foo
[1]: the ELF docs say:
"If a shared object name has one or more slash (/)
characters anywhere in the name, such as /usr/lib/lib2
or directory/file, the dynamic linker uses that string
directly as the path name. If the name has no slashes,
such as lib1, three facilities specify shared object
path searching."
which means it can't be used to search for a library
linked relatively to a search path.
making a DT_FRAMEWORK_NEEDED entry of
"foo.framework/Versions/2/foo"
[Glibc]
will apply the to the DT_FRAMEWORK_NEEDED entry to
framework search path (analogous to LD_LIBRARY_PATH
etc..)
looking for /adir/foo.framework/Versions/2/foo
more information on frameworks available at
http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/index.html
> What parts of the compiler will be modified?
machine-specific code enabling parts of
gcc/config/darwin-c.c for other platforms
adding specs for new ld options
> What will the benefits of your change be? (Be
specific -- for
> example, if you will be improving code quality,
indicate what kind
> of code, and, if possible, how great the
improvement will be.)
be able to use a relocatable self contained directory
which both shared library and header files
with simpler usage than lots of -I/-L or symlinks,
easy cp -R installation and a shared library
versioning mechanism.
> What risks do you foresee? (If you say "none",
you'll be asked to
> resubmit...) What will you be doing to mitigate
those risks?
gcc:
sending options to ld it doesn't understand,
messing up the existing header search path.
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250