[vlc-devel] Re: Fix for apple's dual definition errors
Derk-Jan Hartman
d.hartman at student.utwente.nl
Thu Jul 3 12:35:33 CEST 2003
On donderdag, jul 3, 2003, at 12:11 Europe/Amsterdam, Derk-Jan Hartman
wrote:
> On donderdag, jul 3, 2003, at 00:13 Europe/Amsterdam, John Michael
> Zorko wrote:
>> DJ,
>>
>>> From the web ;)
>>> Look it get's updates.
>>>
>>>> 1. Apple's linker is kind of strange, and the behavior has changed
>>>> between major versions, so some things that didn't generate
>>>> complaints now do and vice versa - the complaints do not
>>>> necessarily indicate a real problem that the compiler is saving
>>>> you from. For example: multiple definitions. Anyway, the magic
>>>> incantation with the latest version of the tools Apple ships is:
>>>> -multiply_defined <error|warn|suppress>. Default is error, but
>>>> suppressing them is usually safe if you think it should be. FWIW,
>>>> the other common bogus compiler error tends to be cured with:
>>>> CFLAGS="-no-cpp-precomp", just in case you or someone else run
>>>> into any other common mac problems.
>>>
>>> sam, Meuuh, i'm sure one of you guys will know where to put this.
>>
>> Yes, but my toolchain did not change at all between VLC CVS from a
>> week ago (when 0.6.0 built on OSX) and VLC CVS now (which does not
>> for me). I tend to think that I updated /usr/local incorrectly. Can
>> someone please check to see if the link points to the correct stuff,
>> and then send me the link again? I'm not sure if the one on the
>> website is the correct one?
>>
>> Regards,
>> John
>
> Your toolchain did not change, but the source did ;)
> This is the correct path.
Some relevent pieces about the linker on multiple defines etc.
TWO-LEVEL AND FLAT NAMESPACES
Two-level and flat namespaces refer to how references to
symbols in dynamic libraries are resolved to a definition
in specific dynamic library. For two-level namespace that
resolution is done at static link time when each image
(program, bundle and shared library) is built. When a
program is using images built with two-level namespace
there may be different global symbols with the same name
being used by different images in the program (this is now
the default). When a program is using all flat namespace
images then only one global symbol for each global symbol
name is used by all images of the program (this was the
default in MacOS X 10.0).
When creating a output file with the static link editor
that links against dynamic libraries, the references to
symbols in those libraries can be recorded at static link
time to bind to a specific library definition (two-level
namespace) or left to be bound at execution time to the
first library in the search order of the program (flat
namespace). A program, its dynamic libraries and its bun-
dles may each be either two-level or flat namespace
images. The dynamic linker will bind each image according
to how it was built.
When creating a output file with the static link editor
when -twolevel_namespace is in effect (now the default)
all undefined references must be satisfied at static link
time. The flags to allow undefined references, -Usym-
bol_name, -undefined warning and -undefined suppress can't
be used. The specific library definition recorded for
each reference is the first library that has a definition
as listed on the link line. Listing an umbrella framework
implies all of its sub-frameworks, sub-umbrellas and sub-
libraries. For any reference to a definition found in an
umbrella framework's sub-framework, sub-umbrella or sub-
library will be recorded as coming from the umbrella
framework. Then at execution time the dynamic linker will
search that umbrella framework's sub-frameworks, sub-
umbrellas and sub-libraries for those references. Also
when two-level namespace is in effect only those frame-
works listed on the link line (and sub-frameworks, sub-
umbrellas and sub-libraries of umbrella frameworks) are
searched. Other dependent libraries which are not sub-
frameworks, sub-umbrellas or sub-libraries of umbrella
frameworks are not searched.
If a two-level namespace static link references a
symbol from an indirectly referenced dynamic
library not listed on the link line the following
error message will result:
ld: object_file illegal reference to symbol:
symbol defined in indirectly referenced
dynamic library: library
To correct the link error the user should add
library to the link line in the order he wants the
library to be searched.
When creating bundles (MH_BUNDLE outputs) with the static
link editor when two-level namespace is in effect (now the
default) and the bundle has references to symbols expected
to be defined in the program loading the bundle, then the
-bundle_loader executable must be used.
When creating a output file with the static link editor
when -flat_namespace is in effect (the MacOS X 10.0
default) all undefined references must be satisfied at
static link time when -undefined error (the default) is
used. The static link editor checks the undefined refer-
ences by searching all the libraries listed on the link
line then all dependent libraries. The undefined symbols
in the created output file are left to be resolved at exe-
cution time by the dynamic link editor in the dynamic
libraries in the search order of the program.
MULTIPLY DEFINED SYMBOLS
If there are multiply defined symbols in the object files
being linked into the output file being created this
always results in a multiply defined symbol error.
When the static link editor links symbols in from a
dynamic library that result in multiply defined symbols
the handling depends on the type of name space of output
file being created and possibly the type of name space of
the dynamic library.
When the static link editor is creating a two-level names-
pace image and a there is a multiply defined symbol from
dynamic library then that generates a multiply defined
symbol warning (by default), where the treatment of this
warning can be changed with the -multiply_defined flag.
When the static link editor is creating a flat namespace
image and a there is a multiply defined symbol from
dynamic library, if the library is a flat namespace image
then that generates a multiply defined symbol error. If
the library is a two-level namespace image then that gen-
erates a multiply defined symbol warning (by default),
where the treatment of this warning can be changed with
the -multiply_defined flag.
-multiply_defined treatment
Specifies how multiply defined symbols in dynamic
libraries when -twolevel_namespace is in effect are
to be treated. treatment can be: error, warning,
or suppress. Which cause the treatment of multiply
defined symbols in dynamic libraries as either,
errors, warnings, or suppresses the checking of
multiply symbols from dynamic libraries when
-twolevel_namespace is in effect. The default is
to treat multiply defined symbols in dynamic
libraries as warnings when -twolevel_namespace is
in effect.
-multiply_defined_unused treatment
Specifies how unused multiply defined symbols in
dynamic libraries when -twolevel_namespace is in
effect are to be treated. An unused multiply
defined symbol is one when there is a symbol
defined in the output that is also defined in the
dynamic libraries the output is linked with but the
symbol in the dynamic library is not used by any
reference in the output. treatment can be: error,
warning, or suppress. The default for unused mul-
tiply defined symbols is to suppress these mes-
sages.
DJ
---
Videolan - VLC media player
Derk-Jan Hartman (thedj at users.sourceforge.net)
Co-Developer of the MacOS X port of vlc
http://www.videolan.org/vlc
--
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>
More information about the vlc-devel
mailing list