Re: flat namespaces redux
On Monday, February 3, 2003, at 01:27 AM, Benjamin Reed wrote: 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. 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 Peter ___ 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
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
Re: flat namespaces redux
On Tue, Feb 04, 2003 at 12:23:04AM +0900, 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. On AIX, libtool does something special if LDFLAGS has "-brtl" in it. Can something be done similarly for OSX to support the two-level namespace (by inspecting CPPFLAGS or CFLAGS or some other variable at ./configure time)? Or do you need a libtool option to do what you want? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Broken exe wrapper script on OS/X
GNU libtool) 1.4.2 Here "$col" refers to an ugly path to a shell script wrapper for the "columns" program. I modified it slightly by adding "set -x" just before the command invocation. As you can see, there seems to be a problem with embedded white space in command line arguments. The argument gets broken in two and my program complains. The platform is an OS/X 10.1 (sourceforge compile farm) == + ls -1 *.[ch] | $col -I4 --spread=1 --line-sep=' XXX' + columns -I4 --spread=1 --line-sep= XXX columns: Command line arguments not allowed columns - Columnize Input Text - Ver. 1.1 USAGE: columns [[ ]] $ ls -1 *.[ch] | $col -I4 --spread=1 "--line-sep=' XXX'" + columns -I4 --spread=1 --line-sep=' XXX' columns: Command line arguments not allowed[[ ]] $ ls -1 *.[ch] | $col -I4 --spread=1 "--line-sep='XXX'" + columns -I4 --spread=1 --line-sep='XXX' autoopts.cautoopts.hboolean.c enumeration.c numeric.c'XXX' options.h pgusage.c restore.c save.cstack.c'XXX' streqv.h streqvcmp.c usage.c version.c $ echo $0 -bash ~/autogen-5.5.2pre8/=Power-Macintosh-Darwin-5.5/pkg/libopts-18.6.9 $ uname -a Darwin usf-cf-ppc-macosx-1 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 PDT 2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC Power Macintosh powerpc BACK ON MY DEVELOPMENT MACHINE: $ libtool --version ltmain.sh (GNU libtool) 1.4.2 (1.922.2.54 2001/09/11 03:33:37) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Broken exe wrapper script on OS/X
Bruce, So what does CVS Libtool do? Robert Bruce Korb wrote: > > GNU libtool) 1.4.2 > > Here "$col" refers to an ugly path to a shell script wrapper > for the "columns" program. I modified it slightly by adding > "set -x" just before the command invocation. As you can see, > there seems to be a problem with embedded white space in command > line arguments. The argument gets broken in two and my program > complains. The platform is an OS/X 10.1 (sourceforge compile farm) > > == > > + ls -1 *.[ch] | $col -I4 --spread=1 --line-sep=' XXX' > + columns -I4 --spread=1 --line-sep= XXX > columns: Command line arguments not allowed > columns - Columnize Input Text - Ver. 1.1 > USAGE: columns [[ ]] > > $ ls -1 *.[ch] | $col -I4 --spread=1 "--line-sep=' XXX'" > + columns -I4 --spread=1 --line-sep=' XXX' > columns: Command line arguments not allowed[[ ]] > > $ ls -1 *.[ch] | $col -I4 --spread=1 "--line-sep='XXX'" > + columns -I4 --spread=1 --line-sep='XXX' > autoopts.cautoopts.hboolean.c enumeration.c numeric.c'XXX' > options.h pgusage.c restore.c save.cstack.c'XXX' > streqv.h streqvcmp.c usage.c version.c > > $ echo $0 > -bash > ~/autogen-5.5.2pre8/=Power-Macintosh-Darwin-5.5/pkg/libopts-18.6.9 > $ uname -a > Darwin usf-cf-ppc-macosx-1 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 PDT >2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC > Power Macintosh powerpc > > BACK ON MY DEVELOPMENT MACHINE: > > $ libtool --version > ltmain.sh (GNU libtool) 1.4.2 (1.922.2.54 2001/09/11 03:33:37) > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[ 100207 ] need_lib_prefix=no for osf*
Support Request #100207, was updated on 2001-Nov-19 12:18 You can respond by visiting: http://savannah.gnu.org/support/?func=detailsupport&support_id=100207&group_id=25 Category: None Status: Closed Priority: 5 Summary: need_lib_prefix=no for osf* By: mooney Date: 2002-Oct-18 22:11 Logged In: YES user_id=3216 Browser: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.2a) Gecko/20020912 Here it is almost a year later, and I'm just now submitting my patch via the official method (rather than on the libtool developer list). It's patch #575 on savannah.gnu.org, against the then-current 1.4b CVS. I found this and found the problem in August of 2001, and reported the problem and fix for gnumeric on bugs.gnome.org (see problem reports 52096 and 58426), since that's where I first discovered it. I reported it quite a bit later on the libtool mailing list, and I think I cc'ed the patch to libtool-patches but don't recall for sure. -- By: bs Date: 2001-Nov-20 03:08 Logged In: NO Browser: Mozilla/4.0 (compatible; MSIE 5.12; Mac_PowerPC) Sorry, but I didn't find a reference to your patch. Otherwise I wouldn't have submitted an almost- identical one. I'm doing the same procedure you describe with packages using libtool/autoconf/automake, but that's quite unsatisfactory. Additionally, tarballs created for distribution have the wrong settings in their configure script causing installs on Tru64 to fail without modification. I'd really welcome your patch to be included in libtool, too. Burkhard. -- You can respond by visiting: http://savannah.gnu.org/support/?func=detailsupport&support_id=100207&group_id=25 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[ 101415 ] libtool + C++ + gcc on solaris
Support Request #101415, was updated on 2002-Oct-18 08:55 You can respond by visiting: http://savannah.gnu.org/support/?func=detailsupport&support_id=101415&group_id=25 Category: None Status: Deleted Priority: 5 Summary: libtool + C++ + gcc on solaris By: rboehne Date: 2002-Oct-22 08:28 Logged In: YES user_id=148 Browser: Mozilla/4.76 [en] (X11; U; OSF1 V4.0 alpha) This is a canned response from the Libtool maintainers regarding your support inquiry. Your inquiry left out the crucial detail of which version of Libtool you are having trouble with. Please read http://www.gnu.org/software/libtool/libtool.html where it concerns posting to the bug-libtool mailing list: If you think you have found a bug in libtool, then you should, in the first instance send as complete a report as possible to this list, including the version of Libtool that you are using. Ideally, you should include the text you get by running config.guess, the text you see when you run configure, and if you can, a patch made with diff -u5 which fixes the problem. If you can send a small script, modelled after the scripts in the tests directory of the distribution which fails with the unpatched distribution, but passes with your patch applied we can add the test to the distribution to make sure the bug doesn't reappear. -- By: David.Decotigny Date: 2002-Oct-18 08:55 Logged In: NO Browser: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1) Gecko/20020827 We have gcc-3.2 here compiled using: --enable-shared --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld When configure runs libtool, it discovers that gcc does not use a GNU ld, which is just the case. So, when creating a shared library, it will be the case that libtool will "manually" invoke the ld (/usr/ccs/bin/ld here). Why not... BUT... The library works fine as long as there are no C++ global objects that are expected to be constructed before main() (ie global objects declared in a c++ source as "MyClass object(init_parameters)). If there are such objects, the behavior any program dynamically linked against the library is to simply ignore them, or to crash in the middle of the objects instanciations... I noticed that building the library manually with "gcc-3.2 -shared" instead of the "ld" command line set by libtool, will result in a correct behavior: everything will be correctly initialized before main(). If I add the crtbegin/crti/crtend objects in the library, it actually seems to work fine too. So the question: why try to guess a (apparently broken) ld command line, since gcc -shared seems to do the job right? -- You can respond by visiting: http://savannah.gnu.org/support/?func=detailsupport&support_id=101415&group_id=25 ___ 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
Pending release of 1.5
Hello, I'm just about to make the release of Libtool 1.5. If anyone would like to test the current CVS on their favorite platform and report any problems, please do so! If not, your woes may have to wait for 1.5.1. Thanks, Robert Boehne ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[ 101415 ] libtool + C++ + gcc on solaris
Support Request #101415, was updated on 2002-Oct-18 09:55 You can respond by visiting: http://savannah.gnu.org/support/?func=detailsupport&support_id=101415&group_id=25 Category: None Status: Deleted Priority: 5 Summary: libtool + C++ + gcc on solaris By: David.Decotigny Date: 2003-Feb-04 02:50 Logged In: NO Browser: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1) Gecko/20020827 This was for version 1.3.5 (solaris 2.7 host) of libtool. Some time ago, someone from the libtool team told me this "bug" was fixed in the CVS version. Actually, I also tried the 1.4.2 version, and it crashed (differently). David Decotigny -- By: rboehne Date: 2002-Oct-22 09:28 Logged In: YES user_id=148 Browser: Mozilla/4.76 [en] (X11; U; OSF1 V4.0 alpha) This is a canned response from the Libtool maintainers regarding your support inquiry. Your inquiry left out the crucial detail of which version of Libtool you are having trouble with. Please read http://www.gnu.org/software/libtool/libtool.html where it concerns posting to the bug-libtool mailing list: If you think you have found a bug in libtool, then you should, in the first instance send as complete a report as possible to this list, including the version of Libtool that you are using. Ideally, you should include the text you get by running config.guess, the text you see when you run configure, and if you can, a patch made with diff -u5 which fixes the problem. If you can send a small script, modelled after the scripts in the tests directory of the distribution which fails with the unpatched distribution, but passes with your patch applied we can add the test to the distribution to make sure the bug doesn't reappear. -- You can respond by visiting: http://savannah.gnu.org/support/?func=detailsupport&support_id=101415&group_id=25 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
