Bugs item #1907829, was opened at 2008-03-05 11:00 Message generated for change (Comment added) made by mr-meltdown You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1907829&group_id=56967
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fabian (mr-meltdown) Assigned to: Sjoerd Mullender (sjoerd) Summary: Building on Darwin should use 2-level namespace Initial Comment: Currently, the building on Darwin (Mac OS X) forces the use of a flat namespace. This is a side-effect of the also issued -undefined suppress, which causes the linker not to complain about undefined symbols that it encounters. Since this is the default on GNU binutils (say, Linux), this flag is enabled by default. Two-Level Namespaces It's possible for more than one library to have a symbol of the same name. In early Mac OS X releases (before 10.1), there was a conflict if more than one library exported a particular name. Since the release of 10.1, Mac OS X has supported "two level" object files. These object files use both the source library (a "namespace") and the name of the symbol for dynamic references, thus eliminating the possibility of conflicts. Since Mac OS X 10.2, two level namespaces have been the default. Note that this problem is still present in other dynamic linkers and flat namespaced programming languages (C, in particular), so most portable software attempts to workaround this deficiency at a higher level than the linker by manging the symbol names. In any case, two-level namespaces are highly recommended, as flat namespaces do NOT behave identially to the flat namespaces of other popular linkers. Most importantly: the first definition of a symbol is used, rather than the last, which can cause serious problems with plugin loading. For this reason, I argue that on Darwin we should build for a 2-level namespace, and just deal with the missing symbols, which the linker finds. In the end they are serious problems anyway. Compiling the current code with -no-undefined in LDFLAGS (for libtool) results in this behaviour and builds 2-level namespace libraries without problems in our own code. This means we're doing fine. The only problem I found, is in php. At the linking there it looks as if -lphp is missing, causing the linker to complain about around 30 missing _php symbols. I made this a bug, because I don't know what is the best way to inject -no-undefined in the LDFLAGS throughout the autotools process. A few notes: - on GNU binutils (Linux) "-no-undefined" does nothing, because on that plaform there simply doesn't exist a mode that checks symbols - "-no-undefined" is not just some sort of 'strictness', when not defined, libtool just forces some last resort 'ignore this' flags onto the linker. Note that this can cause kernel traps during runtime if symbols are missing. - the 2-level namespace is the default on Mac OS X ---------------------------------------------------------------------- >Comment By: Fabian (mr-meltdown) Date: 2008-03-05 11:06 Message: Logged In: YES user_id=963970 Originator: YES another note: - I realise that this is sort of deviating from libtool's default, so I could settle with a decision where "-no-undefined" is only used in --enable-strict ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1907829&group_id=56967 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
