Changes needed for OS/X

Hi, OS/X has cleverly added some DYLD environment variables for telling its loader to do special things. Problems arise when a binary needs to spawn another version of itself when fork() won't do. (The new process needs to start in main() and process arguments.) What happens is that the loader

Re: Why is Guile unable to find libtool?

On Tue, Aug 14, 2018 at 1:54 AM Matthias Klose wrote: > > > $ sudo apt install libtool-devel > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > E: Unable to locate package libtool-devel > > $ type libtool > > bash: type: libtool: not found >

Re: Why is Guile unable to find libtool?

How? I'm sure it is somewhere under /usr but not /usr/local, but now it _is_ under /usr/local 'cuz I did a source install. I'd rather dump that one so I'm not on the hook to update it all the time. On Thu, Jul 26, 2018 at 5:04 PM Brett Gilio wrote: > > > Bruce Korb writes: > > &

Why is Guile unable to find libtool?

$ ./configure . checking for libltdl... no configure: error: GNU libltdl (Libtool) not found, see README. $ type libtool bash: type: libtool: not found $ sudo apt install libtool Reading package lists... Done Building dependency tree Reading state information... Done libtool is already

Re: How to build libtool from git sources properly?

On Thu, May 19, 2016 at 7:22 AM, Eric Blake wrote: > ... However, libtool uses its own > custom bootstrap, and I don't know if it has that same functionality. > Patches are certainly welcome. And it would also be nice if libtool's > own bootstrap could be merged back upstream

Re: How to build libtool from git sources properly?

On 05/18/16 14:41, Bob Friesenhahn wrote: On Wed, 18 May 2016, Igor Zhbanov wrote: run `./bootstrap` -mike It doesn't work on a PC without git or without network connection because it needs to clone gnulib (although there is no gnulib folder in libtool-2.4.6.tar.gz. But this is probably

Re: bootstrap patch

On 01/27/14 06:57, Bruce Korb wrote: Hi Gary, On Sun, Jan 26, 2014 at 6:21 PM, Gary V. Vaughan g...@gnu.org wrote: Anyway, if you want to test for are we in a git repo hierarchy? would not git rev-parse --git-dir be better? No, because bootstrap absolutely has to run in $srcdir, and I don't

Re: bootstrap patch

Hi Gary, On Sun, Jan 26, 2014 at 6:21 PM, Gary V. Vaughan g...@gnu.org wrote: Anyway, if you want to test for are we in a git repo hierarchy? would not git rev-parse --git-dir be better? No, because bootstrap absolutely has to run in $srcdir, and I don't want to $top_srcdir, I would guess.

bootstrap patch

Hi, test -f .git? Do you mean test -d .git? Anyway, if you want to test for are we in a git repo hierarchy? would not git rev-parse --git-dir be better? diff --git a/bootstrap b/bootstrap index 2094e73..b84fa63 100755 --- a/bootstrap +++ b/bootstrap @@ -230,7 +230,7 @@ vc_ignore= # Source

How do I debug this broken link?

The problem is with xml2ag: $ for f in autogen getdefs columns xml2ag ; \ do echo $f; \ ldd /usr/local/bin/$f | fgrep libopts.so ; \ done autogen libopts.so.25 = /usr/local/lib64/libopts.so.25 (0x7ff4c0168000) getdefs libopts.so.25 = /usr/local/lib64/libopts.so.25

Re: $to_tool_file_cmd is empty

On 10/24/12 07:21, Gary V. Vaughan wrote: There is no assignment to to_tool_file_cmd anywhere. It should have been injected into the libtool script, by config.status, which in turn is supposed to contain the expansion of _LT_PATH_CONVERSION_FUNCTIONS. ... If you can do that, then I think

Re: $to_tool_file_cmd is empty

Hi Gary, On Tue, Oct 23, 2012 at 6:04 PM, Gary V. Vaughan g...@gnu.org wrote: lt-func_mode_compile func_to_tool_file alloc.c func_convert_file_msys_to_w32 Are you building on some variant of Windows? OS/X Lion. $to_tool_file_cmd $1 = $to_tool_file_cmd is empty ==

Re: $to_tool_file_cmd is empty

Here ya go. The full log of the autogen.sh run, the configure and the build. The project is bdwgc, whatever that is. $ bash -x ./autogen.sh sh export 'PS4=sh-${FUNCNAME} ' sh PS4='sh-${FUNCNAME} ' sh- do_always sh-do_always export 'PS1=\w\n\$ ' sh-do_always PS1='\w\n\$ ' sh-do_always case $- in

Re: $to_tool_file_cmd is empty

P.S.: $ fgrep to_tool_file_cmd * libtool:*,$to_tool_file_cmd,*) libtool: $to_tool_file_cmd $1 libtool: case $nm_file_list_spec~$to_tool_file_cmd in ltmain.sh:*,$to_tool_file_cmd,*) ltmain.sh: $to_tool_file_cmd $1 ltmain.sh:case

Re: $to_tool_file_cmd is empty

On Wed, Oct 24, 2012 at 7:22 AM, Gary V. Vaughan g...@gnu.org wrote: Hi Bruce, On 24 Oct 2012, at 19:22, Bruce Korb bruce.k...@gmail.com wrote: P.S. Were you able to help Mark Weaver with: user_search_path vs libtool --mode=execute -dlopen ? I'm holding on to the next release until I know

$to_tool_file_cmd is empty

lt-func_mode_compile func_to_tool_file alloc.c func_convert_file_msys_to_w32 lt-func_to_tool_file set -x lt-func_to_tool_file case ,$2, in lt-func_to_tool_file alloc.c ./libtool: line 2088: ./alloc.c: Permission denied $ libtool --version|head -1 libtool (GNU libtool) 2.4.2 #! /bin/sh # libtool

Re: How does one specify linking to 64 bit libraries when there is a choice?

On 12/19/10 20:40, Noah Lavine wrote: Hello, I am not at all an expert on guile-config, but I will help if I can. Thank you to all who responded. Usually if you have 64-bit libs in lib64, you have to pass --libdir explicitly. We've now concluded that that is, indeed, the answer to the

Re: How does one specify linking to 64 bit libraries when there is a choice?

Hi Andy, Ralf, et al., On Mon, Dec 20, 2010 at 6:23 AM, Andy Wingo wi...@oblong.com wrote:   How much understanding of the machinery should be expected   of the hapless project builder? I'm not sure, but: . I am sure of this: It needs to be minimized. If there are insurmountable

Re: How does one specify linking to 64 bit libraries when there is a choice?

Howdy, It is feeling like circular responsibilities to me. So far, the circle seems unbroken. Let's start by enumerating the ways of breaking it and then, perhaps, figure out the easiest way. Currently, it is actually broken by users having to know that for a particular distribution, they have

Re: How does one specify linking to 64 bit libraries when there is a choice?

On 12/20/10 09:11, Nick Bowler wrote: On 2010-12-20 08:54 -0800, Bruce Korb wrote: If the default build is 64 bit, why does it make sense that the default library directory is the 32 bit library? As far as I know, the only reason for this design is to avoid breaking 32-bit proprietary

Re: How does one specify linking to 64 bit libraries when there is a choice?

On 12/20/10 11:20, Ralf Wildenhues wrote: * Bruce Korb wrote on Mon, Dec 20, 2010 at 03:09:48PM CET: How much understanding of the machinery should be expected of the hapless project builder? I've skimmed most of the conversation in this thread now. The crucial part, I think

Re: How does one specify linking to 64 bit libraries when there is a choice?

at 9:39 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Thu, Dec 16, 2010 at 5:39 PM, Bruce Korb bruce.k...@gmail.com wrote: Here is the problem: /bin/sh ../libtool --tag=CC   --mode=link gcc -std=gnu99 -I/usr/local/include \   -pthread -g -O2 -export-dynamic  -o autogen  autogen-ag.o

Re: How does one specify linking to 64 bit libraries when there is a choice?

Hi Nelson, On Fri, Dec 17, 2010 at 9:09 AM, Nelson H. F. Beebe be...@math.utah.edu wrote: The recent exchanges about the /usr/local/lib vs /usr/local/lib64 problem with libtool + autogen + guile gave me a critical clue.  I examined all of the /usr/local/lib64/*.la files, and found dozens that

Re: How does one specify linking to 64 bit libraries when there is a choice?

Hi Nelson, I am nearly certain we (you) have reached a point where libtool folks are going to say, it is Guile, and Guile folks are going to say, it is libtool. I am going to say, I'd like some help from either or both. Because the guile-config invokes the guile binary in order to print out the

Re: How does one specify linking to 64 bit libraries when there is a choice?

On 12/17/10 13:37, Peter O'Gorman wrote: I haven't had a problem with setting --libdir at configure time and then running make make install, do you perhaps recall what packages gave you issues with this? Oh, I misread again, just for a change :( I don't think setting libdir in the

How does one specify linking to 64 bit libraries when there is a choice?

Here is the problem: /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -I/usr/local/include \ -pthread -g -O2 -export-dynamic -o autogen autogen-ag.o ../autoopts/libopts.la \ ../snprintfv/libsnprintfv.la -pthread \ -L/usr/local/lib -lguile -lltdl \ -L/usr/local/lib64

libposix

Hi, I'd still like to wrap up this thing, but it fails in a way I've been unable to diagnose. A reminder, the goal here is to produce a stand alone project that installs a library and headers so that other projects can reduce the number of configury tests required in order to build. The amount

module libposix

Hi, I seem to be missing something and can't quite figure it out. I get these messages during autoreconf: build_libposix autoreconf configure.ac:29: required file `build-aux/ltmain.sh' not found libposix/Makefile.am: object `pt_chown.$(OBJEXT)' \ created both with libtool and without

Re: libtool versioning and ABI

On Wed, Aug 5, 2009 at 2:32 PM, Joseph Garvinjoseph.h.gar...@gmail.com wrote: I read a description of libtool's versioning here: http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html What's confusing to me is that this way of handling versioning doesn't seem to pay

Re: reference to libgcc_s.so.1 without a corresponding run path

Ralf Wildenhues wrote: Hi Bruce, * Bruce Korb wrote on Wed, Oct 01, 2008 at 04:11:41AM CEST: cd ../getdefs ; gmake getdefs gmake[4]: Entering directory `/home/usr/bkorb/tools/ag/autogen-5.9.6pre15/_b/getdefs' top_builddir=.. top_srcdir=../.. PATH=`cd ../columns /dev/null pwd`:$PATH ; export

Re: reference to libgcc_s.so.1 without a corresponding run path

Bob Friesenhahn wrote: On Wed, 1 Oct 2008, Bruce Korb wrote: /home/usr/bkorb/tools/ag/autogen-5.9.6pre15/_b/agen5/.libs/autogen: fatal: libgcc_s.so.1: open failed: No such file or directory Note that this problem is not libtool's fault. For very good reasons (e.g. many applications stop

Re: ltmain.sh (GNU libtool) 2.2

Oh, this might be useful, too:) Thanks in advance - Bruce $ uname -a SunOS vega 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-4 Bruce Korb wrote: Is there someone who can decipher this message? Thanks - Bruce cd ../getdefs ; gmake getdefs gmake[4]: Entering directory `/home/usr/bkorb/tools

Re: libtool wrapper env variable

make LDFLAGS=-static You'll get a real binary, but statically incorporate libraries from the build tree. ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: Testing doesn't work so well, but it builds

Hi Brian, Harlan, and libtool-ers, On Tue, Jun 24, 2008 at 4:59 PM, Brian Utterback [EMAIL PROTECTED] wrote: Bruce is correct that the problem has to do with -R but you don't do -R the way he is using it here. I need to point out that he isn't doing anything with the -R. I have to depend upon

[SCM] GNU Libtool annotated tag, binary-mlb, created. binary-mlb

versions of From Bruce Korb [EMAIL PROTECTED] * doc/libtool.texi: Corrected nother attack of CRLF line * doc/fdl.texi: New file. The license for distributing the * ltdl.m4, ltcf-c.sh, libtool.m4: Use $ac_ext and $ac_objext * ltdl.c: Reformatted. * ltdl.c: Relegate

Re: Announcing Dolt, a drop-in Libtool replacement

Bob Friesenhahn wrote: On Wed, 9 Apr 2008, Eric Blake wrote: | Since shell scripts are not compiled, the size of a shell script has | very little to do with its execution time. On the other hand, recent improvements in autoconf 2.62 proved that we were able to speed up testsuite performance

Re: Shouldn't the definition of maintainer-clean be changed?

Not knowing the guts of this, my only complaint has to do with the help text for ``--clean'' and the lack of consistency WRT ``-c'' being an acceptable alias for it. Benoit Sigoure wrote: Index: autoconf/bin/autoconf.as === RCS

Re: how to turn off shared library notice in output of make install?

Once upon a time, I had a working web page: http://autogen.sourceforge.net/conftest.html (It is down because the underlying OS was upgraded and it was a nuisance to find a build platform that produced binaries that worked correctly on the current platform. I've since learned how to do it, but

Re: 1.5.22 fails to configure on AIX 5.1

Ralf Wildenhues wrote: because, for example, OpenBSD uses a modified pdksh as /bin/sh, and one of the modifications consists of not setting KSH_VERSION any more. :-/ I am at a loss as how to detect this cleanly, suggestions welcome. if test X${RANDOM} != X${RANDOM} -a X${BASH_VERSION+set} =

RE: libtool 1.5.22

*THANK YOU* That fixed my library linking problem (I'm pretty sure)!! (i.e., it now works correctly with out of date installed libraries on my system. Now I have to see if my friend with the most problematic build site is now okay, too. :) THANKS! Regards, Bruce

I'm not getting this --disable-fast-install thing

-- Variable: fast_install Determines whether libtool will privilege the installer or the developer. The assumption is that installers will seldom run programs in the build tree, and the developer will seldom install. This is only meaningful on platforms in which

Re: Notification message levels are too high

Hi Ralf, On Thursday 01 December 2005 12:34 am, Ralf Wildenhues wrote: Do you do DESTDIR installs by default, or what's the reason you get these warnings regularly? I do make distcheck by default and egrep -i 'error|warning' the resulting log file. Of course I ignore the libtool warnings. :)

Notification message levels are too high

Hi, libtool: install: warning: remember to run \ `libtool --finish /home/bkorb/ag/ag/autogen-5.8pre7/_inst/lib' Warnings are generally for the purpose of alerting people to the fact that something correctable leaves the opportunity for errors or hidden problems. The string, warning draws

Re: Notification message levels are too high

On Wednesday 30 November 2005 03:22 pm, Bruce Korb wrote: Hi, libtool: install: warning: remember to run \ `libtool --finish /home/bkorb/ag/ag/autogen-5.8pre7/_inst/lib' Warnings are generally for the purpose of alerting people to the fact that something correctable leaves

Re: [gnu.org #254683] Errors in http://www.gnu.org/software/libtool/contribute.html

On Friday 21 October 2005 10:04 am, Pablo Palazon via RT wrote: Hello I'm GNU webmaster, you can resolve this? [EMAIL PROTECTED] - Mie. Oct. 12 08:28:29 2005]: Hi, I would like to point out what appear to be a couple of errors in the web page

Re: Why am I linking to an installed library?

Another quick question: + relink_command='{ test -z ${COMPILER_PATH+set} || unset COMPILER_PATH || { COMPILER_PATH=; export COMPILER_PATH; }; }; { test -z ${GCC_EXEC_PREFIX+set} || unset GCC_EXEC_PREFIX || { GCC_EXEC_PREFIX=; export GCC_EXEC_PREFIX; }; };

Why am I linking to an installed library?

Hi, On x86 Linux: i686-pc-linux-gnu I just made an extension to the shared library in my pet project. The older version has been installed in /usr/lib via rpm and in /usr/local/lib via make install. /etc/ld.so.conf seems a bit over the top, but looks like this: /usr/X11R6/lib/Xaw95

Cannot bootstrap with libtool 1.5.18

Here's the log from the configure step: configure.in: installing `config/install-sh' agen5/Makefile.am: installing `config/compile' agen5/Makefile.am: installing `config/depcomp' autoopts/Makefile.am:84: Libtool library used but `LIBTOOL' is undefined autoopts/Makefile.am:84:

Re: recommended libtool 1.5.x release

Hi Ralf, On Thursday 07 April 2005 11:50 pm, Ralf Wildenhues wrote: * Bruce wrote on Thu, Apr 07, 2005 at 06:21:09PM CEST: I am about to release another sharutils and another autogen. Is that: in less than two weeks? in approximately not less than. I have to give my uncle an accounting

Re: Invalid switch passed to linker on Solaris 10 with Sun One Studio 8

On Friday 08 April 2005 03:47 am, Ralf Wildenhues wrote: To the other developers: Since this is an annoying bug for many people, are you ok with another point release of 1.5.x? Say, weekend after next? If you want me to do it: how do I read up on getting write approval for uploading? Do it

Re: Now some joy.... 8-O !!

Hi Gary! The solution is at the bottom. I stumbled onto it by playing around with env - prefixes on various commands. On Wednesday 23 February 2005 04:15 am, Gary V. Vaughan wrote: Hallo Bruce! You only need -export-dynamic if you are going to use lt_dlopen (NULL) to get a reflective

Re: I still do not know how to use -rpath with libtool+automake

On Monday 21 February 2005 04:08 am, Gary V. Vaughan wrote: Hallo Bruce! Cc:ing automake list incase I need to be corrected here... Automake generates the -rpath flags for libtool automagically, so you shouldn't try to add your own. The key is in how the libraries are linked, and whether

I'm doing something wrong, but I just don't get it.

I am building both a library and a program that uses it. When they are both installed, I do _NOT_ want it to be necessary for people to have to fiddle with LD_LIBRARY_PATH in order to be able to run the program. I _ALSO_ do not want someone building a new package to be forced to install the new

What might be wrong with my configury?

Hi, To the best of my knowledge, I have not changed the way I've linked in my library, yet something clearly has changed. My library is built with these automake rules/assignments: nodist_libopts_la_SOURCES = libopts.c libopts_la_SOURCES= $(HDRS) libopts_la_LIBADD =

Re: License of m4/ltoptions.m4

Scott James Remnant wrote: On Wed, 2004-11-10 at 14:57 -0800, Paul Eggert wrote: As a special exception to the GNU General Public License, if you distribute this file as part of a package that automatically derives from this file a configuration script (and perhaps some associated

Re: TODO

be bytecompiled. Also Bruce Korb had a play with a compilable libtool in C generated by his autogen project. Things in Libtool have moved along enough that it would probably be easier to take this approach rather than my convoluted idea. The real problem with my approach was that I was doing

Re: Building all static

Gary V. Vaughan wrote: Are these assumptions good? i) people who specify -static to libtool don't want to link against any dynamic libraries, and are suprised that isn't actually the case. ii) the -static option is not used to mean `link static libtool libraries, and dynamic

Re: [MAD SCIENCE EXPERIMENT]: Replace some libtool functionalitywith handcoded C

Mohan Embar wrote: Hi Alexandre, I'm not all that surprised your C program is much faster that the shell script. For starters, it fails to support all of libtool's configure-time options, such as --disable-static, --disable-shared, --with-pic, as well as their per-compilation equivalent

Re: 1,000 year backward compatability of tools

Paul Eggert wrote: Alex Hornby [EMAIL PROTECTED] writes: On a related note, does the restriction of not using shell functions in autoconf macros still remain, For Autoconf itself, we still avoid shell functions. But of course you can use shell functions in your own macros, if you

Re: 1,000 year backward compatability of tools

Charles Wilson wrote: I think the winning argument was as follows: for archaic systems whose shell does not support shfuncs, 'somebody' should create a snapshot of bash with a frozen autotool version That's the argument that has been put forth over and over for years. I couldn't

Re: 1,000 year backward compatability of tools

Harlan Stenn wrote: I guess it's time for me to chime in. Dave Mills expect NTP to compile on anything he can get his hands on. That's very nice. Why does he need to do this? I mean, the compelling reason? I've been lucky so far in that some of the older gear he has is breaking. I do,

[Fwd: AARRRRGGH! Die Libtool, die!]

A forwarded note for emphasizing the importance of having good error messages give good clues to the unclued: Han-Wen Nienhuys hanwen from cs - uu - nl wrote: (desparate frustration mode) Automake, autoconf, libtool. They should be taken out and shot. Perhaps their authors too. (argh)

shell wrapper bug exists in 1.4.3, too

Next step is CVS, but meanwhile, this is the command line in the failing shell script: exec $program ${1+$@} The shell used by the script is /bin/sh. Has there been any change to this under CVS? The example failure (again): $ ls -1 *.[ch]|$col --line-sep=' \' columns: Command line arguments

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

Re: [Mingw-users] Re: Solving the relink exe's libtool problem[take3]

Earnie Boyd wrote: This patch passes my test. What do we need to do to get this accepted into libtool cvs HEAD? + newargz[0] = xstrdup(/bin/sh); This may not be the shell and there is no point allocating it. It is fine to use it from static memory.

Re: How can I link with libguile?

Albert Chin wrote: On Sun, Jan 12, 2003 at 04:24:02PM -0800, Bruce Korb wrote in http://mail.gnu.org/archive/html/libtool/2003-01/msg00035.html : ``libguile'' lives in a place where LD_LIBRARY_PATH must be set (viz., /opt/sfw/lib). What is wrong? What should I be doing to tell libtool

Re: [shell functions, was RE: solving of name conflicts in included.a]

[EMAIL PROTECTED] wrote: Bash uses configure. Bootstrap-Bash could use a frozen version of configure. There certainly won't be any additions to the list of systems with 15+ year old shells, so a bootstrap-bash for hobbyists should work just fine.

Re: tabularized libtool

Tom Lord wrote: Finally, I still wish that a side-effect of the libtool effort was a document/database that explained clearly and concisely how to deal with shared libraries in various environments. As it stands, that information is weaved into convoluted code and the situation is glossed

Re: getting a locally built library

David Bacher wrote: Hi Bruce, I'm having a problem building the latest autogen 5.4.6 on Mac OS X, while the old autogen is installed. When linking the new autogen executable, it finds the old (installed) verison of libopts instead of the new (local) libopts library. This causes

Re: [shell functions, was RE: solving of name conflicts in included.a]

Alexandre Duret-Lutz wrote: Bruce ... 20 year old shells are [not] too old for continued Bruce support. Ick. How completely disgusting. Cheer up and read the Autoconf 2.54c announcement entirely :) You're right. I only read the first 100 lines or so. :-) This is a decade overdue. ;-)

Re: autogen-5.4.5 build bug

Treeve Jelbert wrote: stray 'no' in link spec --- Hi Libtool ( automake?), Here's the Configuration: Source code location: . Compiler: gcc Compiler flags: -march=athlon -mmmx -m3dnow -O3 Host System Type: i686-pc-linux-gnu Install path:

Re: autoreconf misses ltmain.sh

Thomas Dickey wrote: In my opinion it is prohibitive and stupid It's equally stupid to . I think everyone knows that autoreconf is not ready for prime time. From someone who gets cranky when working code breaks because someone thought I shouldn't do things that way, let me say

Why doesn't libtoolize make libtool?

There is no error message and no output and no file. Works fine for one project, but not another. the AC_CONFIG_AUX_DIR(config) works fine in one project, but leaves the ltmain.sh, config.guess and config.sub in the wrong directories for another. I don't remember making any changes that would

Re: PATCH: pointless code removal

Albert Chin wrote: Isn't the use of `$echo $CC` gross? Isn't the whole script just a bit gross anyway? ;-) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: PATCH: pointless code removal

Of course, if you take advantage of this information, then you *MUST* document the fact that later usage DEPENDS upon a space being the first character. The earlier code did not explain the issue. Anyway, thanks again. - Bruce -- Bruce Korb first initial + last name at gnu dot org AG URL: http

Linking libopts on OS X

Hi David, Apparently nobody has experience with libtool duplicating a convenience library in a library link. Therefore, lets try inserting a ``set -x'' in the link. In the libtool script somewhere around line 1600 (it varies), you will find this: # Determine the type of output case

[Fwd: ltmain.in]

$dir/$old_library -- Bruce Korb first initial + last name at gnu dot org AG URL: http://autogen.sourceforge.net ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: PATCH: pointless code removal

Robert Boehne wrote: Bruce: ... I'd say go ahead, if it breaks I'll let you know. ;) The -Xcompiler thingy is *very* necessary though, so make try not to break it. OK. I made the try. :-) If you would try to poke a hole in: http://autogen.sourceforge.net/data/ltmain.in I'd

Re: PATCH: pointless code removal

Hi Alexandre, This wouldn't work with: libtool gcc -c foo.c -Xcompiler -M [['cuz libtool would then think ``-M'' is the source file...]] Automake's depcomp sometimes appends things like `-Wc,-M', but I'm using the equivalent `-Xcompiler -M' here because it seems your patch removes

Re: Get rid of libtool? [was Re: Makefile problems]

the huge script into functions and/or subscripts with documented interfaces would help a lot. The binary-branch is a teensy step in that direction... == Bruce Korb first initial + last name at gnu dot org AG URL: http://autogen.sourceforge.net

Re: Please help: Library search path question

jks wrote: Hello all, For some reason I keep getting a cannot open shared object file error, even though I have added the library location (/usr/local/lib) to ld.so.conf. I did export LD_DEBUG=libs and got the output listed below, indicating that /usr/local/lib is not being searched,

Re: libtoolize's updatemsg

[EMAIL PROTECTED] wrote: Sorry if the following phenomenon is not a problem. I executed 'libtoolize' and got a message like this: === You should add the contents of `/usr/local/share/aclocal/libtool.m4' to `aclocal.m4'.

Re: autogen on macosx/darwin

Todd Gureckis wrote: A libtool question: which should work correctly and always give _STR something to stringify. okay that worked... now: /bin/sh ../libtool --mode=link cc -g -O2 -o libopts.la -rpath /usr/local/lib -version-info 11:0:2 autoopts.lo boolean.lo enumeration.lo

Re: ltdl.c and 1.4.1 (type conflicts)

Tim Mooney wrote: Something similar to what's done on page 147 (section 6.7) of KR2e -- KR2e == ANSI Of course, most of the functions still use the KR style arg definitions. KR1e. Maybe it should be switched to using ANSI only, and people should be advised to use `ansi2knr' if they need

Re: libtool RFE

Guido Draheim wrote: [EMAIL PROTECTED] wrote: On Tue, Sep 11, 2001 at 12:14:42PM -0700, Bruce Korb wrote: It seems I need to be able to build both 32 and 64 bit libraries. Since nobody seems to have anything to do, maybe we can add this to our copious spare time activities

libtool RFE

It seems I need to be able to build both 32 and 64 bit libraries. Since nobody seems to have anything to do, maybe we can add this to our copious spare time activities: Construction of multiple output libraries based on more than just the -PIC compiler flags. viz., the ``-xarch=v9

Re: MLB merge is done! Hurray! -- Fooey ;-)

Gary V. Vaughan wrote: Hello Libtoolers! Hello again. I guess that means I have some work to do, too :-) Thanks Gary. :-) Anyway, I would like to declare MLB officially dead, and reopen HEAD for development. I would enormously appreciate any help with draining the patch queue (i.e.

Re: [ 100058 ] 1.4 - $buildir-path may not contain ~

Gary V. Vaughan wrote: ... you have to bear in mind that the libtool source code goes through m4, sed and bourne shell, as well as having an autoconf pass to subsitute configure time vars, so the quoting is hairy and sensitive to change. Meta characters to sed, m4, autoconf or any shell

Re: libtool 1.4 failure on Solaris 8

This patch got me through the ugly ethereal build. I applied them to libtool, so obviously they need to be applied to the ltmain.in file. I do not know if every one of these is strictly required, I started getting impatient. :-) Regards, Bruce $ gdiff -u libtool /tmp/LIBTOOL ---

Re: libtool 1.4 failure on Solaris 8

[EMAIL PROTECTED] wrote: On Thu, Jun 07, 2001 at 10:48:04AM -0700, Bruce Korb wrote: Building ethereal: Making all in gryphon /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I/u/local/include -I../.. -I../../wiretap -I../../epan -I/usr/local

Re: Line length limitations

[EMAIL PROTECTED] wrote: On Wed, Jun 06, 2001 at 01:10:14AM -0300, Alexandre Oliva wrote: On Jun 5, 2001, Robert Boehne [EMAIL PROTECTED] wrote: So I'm sure how to check the limits under SGI without the 'wc' command. Use cmp. Ok, I wrote a short test script to do what I want.

John David Anglin - Re: objc/2902: collect2 doesn't ...: libtool should use collect2?

http://gcc.gnu.org/ml/gcc-bugs/2001-05/msg00749.html Title: John David Anglin - Re: objc/2902: collect2 doesn't ...: libtool should use collect2? This is the mail archive of the [EMAIL PROTECTED] mailing list for the GCC project. Index Nav: [DateIndex]

Re: [MLB] BUG in install when piecewise linking

Robert Boehne wrote: Can we get around these problems easier in the binary-branch? Not for a while. First, we have to settle out all the fixes that went into the mainline, but not MLB. (binary is MLB-current). I envision a binary libtool that could do all of the processing itself, without

Windowed Libtools

Wont be able to develop ... libtool *ON WINDOWS* any more. So you're agreeing that the generated ltmain.in must support Cygwin at least as well as the current release? Of course. (wait a minute, thats not exactly what I meant, since the Cygwin port is broken at the moment :-/) at

Re: I think binary-branch is almost ready for play time

Gary V. Vaughan wrote: Hi Bruce, This is how I envision the logistics of integrating your branch to avoid CVS merge hell: * Finish the MLB-HEAD merge. * Flush the patch queue (for HEAD and branch-1-4) * Release libtool-1.4.1 (libtool-1.4-p1?) from branch-1-4

Re: I think binary-branch is almost ready for play time

Gary V. Vaughan wrote: Hi Bruce, On Monday 14 May 2001 1:31 am, Bruce Korb wrote: When this invocation fires, an anonymous template is created with that text and then processed. The output is redirected to an unlinked file (no Windows here), and read back in. Eeek! I

Re: I think binary-branch is almost ready for play time

Alexandre Oliva wrote: In other words, your new macro should not need to do this: [= test-and-exit test = (get test) ... =] because it would be redundant. Good. But I had meant to write ``I'd like *you* to implement ...'' :-) Then I would need to understand better what you

Re: $ in source file names

Robert Boehne wrote: Bruce: I like your ideas, I've been fighting to get libtool to build libraries of arbitrary size, and doing it in C would be so much easier. ... So, I would like to work with you and make sure that ... Thank you :-). So far, it is a trivial map between current and

libtool on macppc-apple-netbsd is not happy (neither am I )-:

../agen5/autogen -T agman1 -L ../autoopts -b getdefs ./opts.def /usr/local/lib/libguile.so: warning: tmpnam() possibly used unsafely, use mkstemp() or mkdtemp() /home/bkorb/tools/autogen-5.1.3/autoopts/.libs/libopts.so.9: Unsupported relocation type 10in non-PLT relocations *** Error code 1

Re: $ in source file names

Tom Tromey wrote: Alexandre [...] in fact, until libtool supports correctly Alexandre file names containing `$' and line-feeds, I won't be Alexandre convinced we do the right thing regarding single-evaluation Alexandre of arguments. And as Alexandre knows, we've already run into problems

  1   2   >