Re: flat namespaces redux
On Mon, Feb 03, 2003 at 11:59:03PM -0600, Robert Boehne wrote: Maybe I don't understand OS X, but as I see it, any library that needs a two level namespace would not build on any other OS because OS X is the only OS that supports this feature. Now, if that is the case, it doesn't make any sense for Libtool (a tool for portable library creation use) to support a feature that is only present on a single platform. Does that make sense? I think we should support the two-level namespace, even if it is OSX-specific. I look at libtool more as a way to easily build shared libraries across multiple platforms. Think about AIX. An AIX shared library (non-brtl) can contain *both* a static and shared member. We don't emulate this across all platforms. And, how about this warning in ltmain.in (a non-portable feature): echo *** Warning: Linking the shared library $output against the echo *** static library $deplib is not portable! deplibs=$deplib $deplibs -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: flat namespaces redux
From my point of view, portable software just means that it should work well in regards to platform-specific features (or bugs). yves Le Mardi, 4 févr 2003, à 00:59 Canada/Eastern, Robert Boehne a écrit : Hello, Maybe I don't understand OS X, but as I see it, any library that needs a two level namespace would not build on any other OS because OS X is the only OS that supports this feature. Now, if that is the case, it doesn't make any sense for Libtool (a tool for portable library creation use) to support a feature that is only present on a single platform. Does that make sense? Robert Boehne Peter O'Gorman wrote: On Tuesday, February 4, 2003, at 12:01 AM, Benjamin Reed wrote: cc -multiply_defined suppress -prebind blah || cc -flat_namespace -undefined suppress blah 1. libkdeui's LIBADD is -lkdecore 2. the first half of the link complains that -lqt-mt is indirectly referenced 3. it builds the library flat, and continues on when what *should* happen is it dies at #2, and we add -lqt-mt to libkdeui's LIBADD like it should be. Why? An option to stop if two_level namespace can't be built, I can see as a good thing for people porting stuff to darwin, however some stuff is quite happy being flat, even if it only missing the usual environ symbol, and imo, libtool shouldn't die by default. The default should be to continue if possible unless told otherwise, the fewer people who have to add custom flags and options the better. Peter ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: flat namespaces redux
Albert, Ok, I'd agree with that mostly, but in the case of AIX, Libtool doesn't build a single archive with both shared and static, it does the same thing it does on other platforms. In the same way it wouldn't be of much use if Libtool did do this, but perhaps some AIX diehards would like it. If there was a patch posted that worked similar to the AIX -brtl trigger to allow for twolevel namespaces, and it didn't change default behavior, I would consider it. Still, regardless of how it is done, all that twolevel namespace support will do is allow severely broken libraries to build on a single platform. Rather than fix them to work with a flat namespace, like every other platform. I liken this to encouraging bad behavior, but if someone cares to make and test a patch that checked for LDFLAGS containing -twolevl (or whatever the link flag is) I'd be willing to approve it if done properly. Even so, isn't it nearly pointless? For this feature to really be useful a library would have to be a) Initially developed on OS/X b) dependent on two level namespace c) not really useful on any other plaform (no reason to fix for a flat namespace) I don't think there are too many libraries that would fit this criteria, but please, correct me if I'm wrong. In short, I'm not dead set against the idea, I just don't see the point. Robert Albert Chin wrote: On Mon, Feb 03, 2003 at 11:59:03PM -0600, Robert Boehne wrote: Maybe I don't understand OS X, but as I see it, any library that needs a two level namespace would not build on any other OS because OS X is the only OS that supports this feature. Now, if that is the case, it doesn't make any sense for Libtool (a tool for portable library creation use) to support a feature that is only present on a single platform. Does that make sense? I think we should support the two-level namespace, even if it is OSX-specific. I look at libtool more as a way to easily build shared libraries across multiple platforms. Think about AIX. An AIX shared library (non-brtl) can contain *both* a static and shared member. We don't emulate this across all platforms. And, how about this warning in ltmain.in (a non-portable feature): echo *** Warning: Linking the shared library $output against the echo *** static library $deplib is not portable! deplibs=$deplib $deplibs -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: flat namespaces redux
On Tue, Feb 04, 2003 at 09:56:47PM -0600, Robert Boehne wrote: [snip snip] For this feature to really be useful a library would have to be a) Initially developed on OS/X b) dependent on two level namespace c) not really useful on any other plaform (no reason to fix for a flat namespace) I don't think there are too many libraries that would fit this criteria, but please, correct me if I'm wrong. In short, I'm not dead set against the idea, I just don't see the point. I have no clue when it comes to OSX. However, the only reason I support this is the impression I get that two-level namespaces are good for OSX. Is this true? Does Apple *recommend* flat or two-level namespaces? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: flat namespaces redux
Albert, Well, I'm not sure about what Apple recommends, I think the two level namespace linker is the result of the ld team at Apple being too low in the food chain. ;) If there were a good reason (like this one) that would change the picture. Part of the problem is that OS X is quite odd, and I don't have one on my desk to poke at or read docs for. Because of that, I'm not really sure what to do with it in many respects. Robert Albert Chin wrote: On Tue, Feb 04, 2003 at 09:56:47PM -0600, Robert Boehne wrote: [snip snip] For this feature to really be useful a library would have to be a) Initially developed on OS/X b) dependent on two level namespace c) not really useful on any other plaform (no reason to fix for a flat namespace) I don't think there are too many libraries that would fit this criteria, but please, correct me if I'm wrong. In short, I'm not dead set against the idea, I just don't see the point. I have no clue when it comes to OSX. However, the only reason I support this is the impression I get that two-level namespaces are good for OSX. Is this true? Does Apple *recommend* flat or two-level namespaces? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: flat namespaces redux
Well, I think that building thing two level namespace ought to be the libtool default also, flat_namespace is needed for some things but causes problems for many others, how about trying both by default? cc -multiply_defined suppress -prebind blah || cc -flat_namespace -undefined suppress blah I'm not so sure this is a good idea. Seems like this would make things harder for packages, since problems *besides* the namespace could also force it into building flat. Say I'm building libkdeui, which depends on libkdecore and qt. If the link line was written on a linuxy system (ie, the linker allows indirect library references), it would end up doing something like: 1. libkdeui's LIBADD is -lkdecore 2. the first half of the link complains that -lqt-mt is indirectly referenced 3. it builds the library flat, and continues on when what *should* happen is it dies at #2, and we add -lqt-mt to libkdeui's LIBADD like it should be. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: flat namespaces redux
Hello, Maybe I don't understand OS X, but as I see it, any library that needs a two level namespace would not build on any other OS because OS X is the only OS that supports this feature. Now, if that is the case, it doesn't make any sense for Libtool (a tool for portable library creation use) to support a feature that is only present on a single platform. Does that make sense? Robert Boehne Peter O'Gorman wrote: On Tuesday, February 4, 2003, at 12:01 AM, Benjamin Reed wrote: cc -multiply_defined suppress -prebind blah || cc -flat_namespace -undefined suppress blah 1. libkdeui's LIBADD is -lkdecore 2. the first half of the link complains that -lqt-mt is indirectly referenced 3. it builds the library flat, and continues on when what *should* happen is it dies at #2, and we add -lqt-mt to libkdeui's LIBADD like it should be. Why? An option to stop if two_level namespace can't be built, I can see as a good thing for people porting stuff to darwin, however some stuff is quite happy being flat, even if it only missing the usual environ symbol, and imo, libtool shouldn't die by default. The default should be to continue if possible unless told otherwise, the fewer people who have to add custom flags and options the better. Peter ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: flat namespaces redux
On Sunday, February 2, 2003, at 11:23 AM, Benjamin Reed wrote: He suggested changing it to -multiply_defined suppress prebind, which seems to be the solution, if libtool doesn't want to support specifying the namespace on the libtool command-line. This would make libtool default to making twolevel libraries (which is darwin's linker default, in fact), but you could still pass -flat_namespace -undefined suppress to the command-line if you have a poorly behaving app. Hrm, replying to myself, sign of a schizophrenic. =) It was also brought up that one of the reasons for having libtool understand namespaces is to have the ability to transition stuff that currently depends on flat namespaces to build, but doesn't know it. Making it an option would let us leave flat as the default, but provide the ability to work with package maintainers to get things building twolevel that can. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
