Re: Introducing a new maintainer of libtool

lly upsets you and needs >> to be backed out. Don't look at more patches until a first pretest >> release is out, IMHO, as I'm sure one can go mad pondering implications >> of a libtool patch forever... > > Thanks, it seems like the general consensus is to get a release out &g

Re: Introducing a new maintainer of libtool

Welcome Ileana! Mike Frysinger writes: > On 13 Jan 2024 14:49, Ileana Dumitrescu wrote: >> My short term plans are to review the numerous mailing list patches and >> get them merged in. This will be an easy and productive first step for >> me and libtool. I will als

Re: Q: Forcing a -Wl,-rpath arg to static lib users

Bob Friesenhahn wrote: > On Wed, 16 Nov 2022, Oleg Smolsky wrote: >> >> Leaving it here for posterity. Perhaps someone will do this with a bit more >> finesse and turn it into a proper feature. > > Are you using libtool as originally distributed by the FSF or are you

libtool.m4 bug (spaces detection in compiler's output after -L/-R)

hen +   if test x-L = "x$p" || +  test x-R = "x$p"; then prev=$p continue     fi Regards, Igor. _______ https://lists.gnu.org/mailman/listinfo/libtool

Re: shared object not being created when building with QNX toolchain

red object linking impossible. Thanks anyway. s1341 On 18 February 2016 at 15:09, s1341-libtool <libt...@shmarya.net> wrote: > Replying to my own question, as I've refined the test case. > > This is the updated Makefile.am: https://ghostbin.com/paste/9wj6d. > > Note that

Re: shared object not being created when building with QNX toolchain

makefile, there were just some symlinks created in .libs. The libfrida-agent.so is expected to be generated and installed into the lib directory, but it is not generated. The install target fails with this output: ``` libtool: install: /usr/bin/install -p .libs/libfrida-agent.so /home/srubenst/github

shared object not being created when building with QNX toolchain

, nm, ...). I've been struggling with this for a few days now, and I can't seem to get it to work. I'd appreciate any insight or suggestions, as I don't really know how to proceed with this. Thanks s1341 ___ https://lists.gnu.org/mailman/listinfo/libtool

[PATCH] Add test case for 69e77671 (cwrapper PATH manipulation order)

* tests/cwrapper.at: Add new test 'cwrapper and installed shared libraries.' --- This patch was actually proposed by Roumen Petrov here: http://lists.gnu.org/archive/html/bug-libtool/2009-12/msg00037.html He mentioned here: http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00222.html

Re: [PATCH] [cygwin|mingw] Create UAC manifest files.

of executable name. My gripe was that any file created by libtool will overwrite the file generated by cl.exe and I think cl.exe will do a better job of creating the manifest. My msvc patches then has code to embed the manifest into the executable using mt (manifest tool), but that is immaterial

Re: [PATCH] [cygwin|mingw] Create UAC manifest files.

can instead create a second file with the following content: 1 24 MOVEABLE PURE progname.manifest and then $ windres progname.rc progname.rc.o $ ld -o new-progname.exe progname.exe progname.rc.o $ mv new-progname.exe progname.exe But that's overkill for the libtool cwrappers, and probably also

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static

files for information. Or is this purely for import libraries not created with libtool (and people who throw away *.la files)? The information (e.g. library to dlpreopen) is passed in $dlprefiles. But, if that filename is .la: func_mode_link(): ... dlfiles|dlprefiles) if test

Re: [Patch] cwrapper invokes target directly

entirely for $host=cygwin|mingw' was a libtool-2.4 project. However, the current libtool-2.2 behavior was an unreported (!) regression over 1.5.x, and the conversation last week seemed to imply that it was important enough to try to fasttrack before 2.4...but that doesn't mean it will or can get

Re: v1.5.27a 'syntax error' in numerous packages

Since _LT_DECL does not appear in the stable branch, except for in a ChangeLog entry, I believe that aclocal is getting confused and bringing in bits of libtool-2.2 as well as bits of libtool-1.5. ltoptions.m4 from libtool-2.2 has this line. that would imply that i did not clean-house

Re: v1.5.27a 'syntax error' in numerous packages

looks like you were correct about a straggler from other installs ... whereas my 'usual' cd /usr/local rm -rf include/ltdl.h lib/libltdl* share/libtool share/aclocal-1.10/ltdl.m4 lib/libdl* (rebuild libtool from src) was not sufficiently 'cleansing', a cd /usr/local rm -rf include/ltdl.h

Re: branch-2-2?

what? who? git? (off to dig through archive ...) ___ http://lists.gnu.org/mailman/listinfo/libtool

what's recommended if tests are failing?

://lists.gnu.org/mailman/listinfo/libtool

Re: what's recommended if tests are failing?

you see in the new improved tests to [EMAIL PROTECTED], so that we can fix them in time for 2.2.2 next month. already done the other day. pending ... :-) ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: GNU Libtool 2.2 released.

hi, a new *build* of libtool (Build: 1.2599 2008/03/02 00:05:01) 2.2 from cvs seems ok (no noticed errors) on OSX 10.5.2, Darwin Kernel Version 9.2.0: Tue Feb 5 16:15:19 PST 2008; root:xnu-1228.3.13~1/RELEASE_PPC w/ automake --version automake (GNU automake) 1.10.1 autoconf

Re: GNU Libtool 2.2 released.

hi, db's configuration requires it to know the shared library extension at configure time, it does this by running the generated libtool script. It is possible to generate one during configure, but it does not do so by default. yup. from my own, long-ago email from sleepycat support

Re: 'make' w/ latest 1.5-branch (1.5.27a) fails @ X--tag=CC: command not found

ltmain.sh is from libtool-2.1b, aclocal.m4 has libtool.m4 from 1.5.27, and then later ,via m4_include, includes libtool.m4 from 2.1b. You have created a monster! heh, well, ok then! :-) i'm honestly confused though, as to what/why/how ... e.g., where is 2.1b coming from? am i just lucky

Re: 'make' w/ latest 1.5-branch (1.5.27a) fails @ X--tag=CC: command not found

Looks like libidn includes libtool-2.1b. honestly, it never dawned on me to check -- 1st time i've ever come across an app that has *newer* libtool than my self built. rm m4/lt* m4/libtool.m4 build-aux/ltmain.sh Then retry your glibtoolize autoreconf. that did the trick! thx! i *thought

Re: 'make' w/ latest 1.5-branch (1.5.27a) fails @ X--tag=CC: command not found

If you wait just 24 hours or so, I'll release 2.2 proper. and that sounds like a plan! thx. We've tried to maintain full backwards compatibility with 1.5.x, ... If autoupdate doesn't migrate ... then that's a bug in the libtool release... clear. thx again

'make' w/ latest 1.5-branch (1.5.27a) fails @ X--tag=CC: command not found

hi, i've glibtool --version ltmain.sh (GNU libtool) 1.5.27a (1.1220.2.497 2008/02/14 23:48:55) installed on uname -v Darwin Kernel Version 9.2.0: Tue Feb 5 16:15:19 PST 2008; root:xnu-1228.3.13~1/RELEASE_PPC atm, i'm building latest IDN, ftp://alpha.gnu.org/pub/gnu/libidn/libidn-1.5

Re: [cygwin] cwrapper emits wrapper script

On Wed, 06 Jun 2007 09:43:50 -0500, Peter O'Gorman said: I'm lazy and would like to avoid work as much as possible, Gary has already asked if you'd like a commit bit, I'm hoping you'll agree, then all we'll need to do is say ok and you can commit your changes yourself. As long as somebody

Re: New libtool is in the GCC and Src trees.

. As such it works just fine as is. Well, it /did/ -- until the new-libtool merge. Now there seem to be build problems. So /something/ needs fixin'. g Also, libgcj has some local libltdl patches as well. Then they should be submitted upstream -- if they are still necessary. There have been a lot

Re: [cygwin] Analysis for new testsuite failures 33,34.35

On Mon, 26 Mar 2007 20:39:24 +0200, Ralf Wildenhues said: Hi Charles, Thanks for the bug report. * Charles Wilson wrote on Fri, Mar 23, 2007 at 07:32:12AM CET: ../../libtool-HEAD/tests/subproject.at:56: $MAKE all $tst_dist + make all dist [...] mkdir: cannot create directory

Your message to Libtool-commit awaits moderator approval

Your mail to 'Libtool-commit' with the subject Sat, 26 Jun 2004 13:25:15 -0600 Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive

The results of your email commands

Free when you sign up an account. No credit card required http://ace.casino.cls2.org/iwin.html James ---End Message--- ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool

Your message to Libtool-commit awaits moderator approval

Your mail to 'Libtool-commit' with the subject Libtool Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification

The results of your email commands

Free when you sign up an account. No credit card required http://acecasino.cls2.org/iwin.html James ---End Message--- ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool

Your message to Libtool-commit awaits moderator approval

Your mail to 'Libtool-commit' with the subject Affiliate Marketers Needed Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive

The results of your email commands

B.Dawn Howell ---End Message--- ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool

[no subject]

-Mailman-Version: 2.1.4 Precedence: list Reply-To: [EMAIL PROTECTED] List-Id: Discussion list for the GNU libtool shared library maintenance tool libtool.gnu.org List-Unsubscribe: http://mail.gnu.org/mailman/listinfo/libtool, mailto:[EMAIL PROTECTED] List-Archive: http://mail.gnu.org

[no subject]

PROTECTED] X-Mailman-Version: 2.1.4 Precedence: list Reply-To: [EMAIL PROTECTED] List-Id: Discussion list for the GNU libtool shared library maintenance tool libtool.gnu.org List-Unsubscribe: http://mail.gnu.org/mailman/listinfo/libtool, mailto:[EMAIL PROTECTED] List-Archive: http

Your message to Libtool-patches awaits moderator approval

Your mail to 'Libtool-patches' with the subject (no subject) Is being held until the list moderator can review it for approval. The reason it is being held: Message has implicit destination Either the message will get posted to the list, or you will receive notification

The results of your email commands

--- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

:)

Argh, i don't like the plaintext :) 71074 -- archive password attachment: Attach.zip ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

The results of your email commands

--- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: Intel icc and shared libs

, Carl ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: version mismatching with ltconfig when building oaf-0.6.5 from src.rpm

version `1.3.5' After reading through your fine archive and attempting to build this manually, I figured out that if you suspend the rpm build after seeing the creation of libtool, and run (from the top level) './ltconfig ./ltmain.sh', then continue the rpm build, it builds properly. Funny

hardcode_into_libs=yes for Tru64 UNIX, IRIX, AIX 4.x

Any objection to setting hardcode_into_libs=yes (currently hardcode_into_libs=no) on Tru64 UNIX 4.x, 5.x, IRIX 6.x, and AIX 4.x, 5.x? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo

Re: C++ exceptions fail, CVS libtool, gcc 3.0.1, Solaris 2.6

On Wed, Oct 03, 2001 at 09:27:41PM -0500, Bob Friesenhahn wrote: ImageMagick has been using CVS libtool. With gcc 2.95.2, C++ exceptions work fine under Solaris 2.6. With gcc 3.0.1, C++ exceptions are not being caught, causing the program to core dump. Has anyone else seen this problem

Re: libtool 1.4 not passing linker directives

On Fri, Oct 05, 2001 at 01:14:52AM -0400, Ian Peters wrote: An application I work on has been calling libtool (through automake) with linker directives on the libtool line, around many of the libraries specified, like so (apologies if this wraps strangely, it's all one line): /bin/sh

Re: _LT_AC_TAGCONFIG versus Cray sed

On Thu, Oct 04, 2001 at 09:05:18AM +1000, Kevin Ryde wrote: On an sv1-cray-unicos10.0.0.X with the cvs libtool I noticed the following error, configure: creating libtool sed: 1: s/[-_ABCDEFGHIJKLMNOPQR ...: RE error: [ ] imbalance or syntax error appending

Re: libltdl crashes under Solaris LP64 64-bit model

. Then why not make argz_len size_t? Nothing else in foreach_dirinpath uses argz_len so it would seem more correct. Index: ltdl.c === RCS file: /home/cvs/libtool/libltdl/ltdl.c,v retrieving revision 1.159 diff -u -r1.159 ltdl.c

Re: AC_LTDL_DLLIB in HEAD/ltdl.m4

the situation where we build on a system with the patch but deploy on a system without, use shl_load exclusively if found. Index: ltdl.m4 === RCS file: /cvsroot/libtool/libtool/ltdl.m4,v retrieving revision 1.36 diff -u -3 -p

Re: HEAD and different C, C++ compilers

=== RCS file: /cvsroot/libtool/libtool/libtool.m4,v retrieving revision 1.233 diff -u -3 -p -r1.233 libtool.m4 --- libtool.m4 2001/09/21 03:06:40 1.233 +++ libtool.m4 2001/09/21 06:32:49 @@ -2558,8 +2558,9 @@ case $host_os in else

Re: Different linkers at different times?

On Fri, Sep 21, 2001 at 02:57:21PM -0500, Kenneth Pronovici wrote: I'm cross-posting this to the autoconf and libtool lists, because I'm not sure whose jurisdiction this is. I accidentally found this while trying to compile libxml2-2.4.5 under Solaris. I say accidentally because

HEAD and different C, C++ compilers

Does HEAD support *different* a different C and C++ compiler (e.g. native vendor C and GNU C++)? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool does not preserve -xarch=v9

On Thu, Sep 20, 2001 at 09:38:29PM -0500, Bob Friesenhahn wrote: 64-bit compilation under Solaris Sun's compiler requires that the argument '-xarch=v9' be provided when compiling C++ objects. Unfortunately libtool (1.4a (1.641.2.259 2001/06/04 19:32:47)) is discarding this argument (which

AC_LTDL_DLLIB in HEAD/ltdl.m4

and defines them all in libtldl/ltdl.c. Why? Why not just pick the first we find? The current behaviour uses shl_load and dlopen on HP-UX by default. I'd like to get this changed to shl_load only. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing

HEAD and HP-UX C++ compiler

}, {nm_test_func, (lt_ptr_t) nm_test_func}, {0, (lt_ptr_t) 0} }; #ifdef __cplusplus } #endif So, do we ignore main on HP-UX with aCC? BTW, G++ 3.0.1 failes too. Solaris C++ (5.3) works fine. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL

Re: libtool RFE

the library you've created, do you then generate both 32 and 64-bit versions as well? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool RFE

On Tue, Sep 11, 2001 at 04:26:16PM -0500, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: libtool RFE Date: Tue, 11 Sep 2001 16:05:17 -0500 Are you aware of any OS that supports 32 and 64-bit libraries in the same directory? I know Solaris

Re: libtool broken in kdebase 2.2.0

]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

this test case though, how can I use ltdl in a program that is used to create libtool? Just so I'm on the same page, this is to autodetect $libltdl_cv_sys_dlopen_deplibs correct? If so, why do you want to use ltdl at all? Isn't it enough to write the following test programs during the run of ltdl.m4

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

not looked too much into ltdl, don't know how difficult it would be. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

are documented to act. You are correct. I incorrectly worded what I meant. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

is not in the application RPATH, should libltdl_cv_sys_dlopen_deplibs still be yes for this platform? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 diff -ur libtool-1.4b.orig/ltdl.m4 libtool-1.4b/ltdl.m4 --- libtool-1.4b.orig/ltdl.m4 Thu Jul 5 18:10:26 2001 +++ libtool-1.4b/ltdl.m4 Mon

Re: libtool: not configured to build any kind of library

On Wed, Jun 27, 2001 at 12:43:18PM +0200, Gabriele Bartolini wrote: I am trying to port my application, ht://Check, to libtool 1.4, the latest stable release. I have no difficult when building the application whether with shared or static libraries support. But I am having some

Search paths with duplicated .la libraries

Say I have: /opt/dir1/ libfoo.a libfoo.la /opt/dir2/ libfoo.so libfoo.la If I: libtool --mode-link cc -L/opt/dir2 -L/opt/dir1 ... then libtool uses /opt/dir2/libfoo.la. However, if I: libtool --mode-link cc -L/opt/dir1 -L/opt/dir2 ... then libtool uses /opt/dir1

Re: Line length limitations

___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool 1.4 failure on Solaris 8

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/include -I/u/local/include -Wall -g

Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]

(libGL-1.2.xxyyzz.so). -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: Line length limitations

=$_sed fi done done echo $_best_sed ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: Line length limitations

to the point of warning you in case sed is broken if you use long command lines. I can't think of any reasonable way to make it work in this case. Would you accept a patch to libtool to locale a better sed on the system? On solaris, /usr/xpg4/bin/sed works better than /usr/bin/sed. I imagine

1.4 oddity

ltmain.in from libtool 1.4 has: # Do each of the archive commands. if test -n $export_symbols test -n $archive_expsym_cmds; then eval cmds=\$archive_expsym_cmds\ else eval cmds=\$archive_cmds\ fi IFS=${IFS= }; save_ifs=$IFS; IFS='~' for cmd in $cmds; do IFS=$save_ifs

Re: 1.4 oddity

On Mon, May 21, 2001 at 09:37:29PM -0500, [EMAIL PROTECTED] wrote: ltmain.in from libtool 1.4 has: # Do each of the archive commands. if test -n $export_symbols test -n $archive_expsym_cmds; then eval cmds=\$archive_expsym_cmds\ else eval cmds=\$archive_cmds\ fi IFS

Re: libtool litter

On Fri, May 11, 2001 at 09:30:32PM -0400, John David Anglin wrote: With the current cvs source for the branch, I find that libtool is leaving an incredible amount of litter in /usr/tmp. I am getting hundreds if not thousands of files like: # cat sh17740.3 int main

Re: $whole_archive_flag_spec and AIX

the same problem. -- albert chin ([EMAIL PROTECTED]) Albert: The GNU coding standards don't let you use 'wc' for general Libtool code, you may be able to get away with it here if 'wc' is available by default on all the machines this code would be used on. I would also like you

$whole_archive_flag_spec and AIX

like an acceptable solution? The only problem with this is if files in $convenience have spaces in the filename. But the Solaris solution above has the same problem. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http

use of $host_os in ltmain.in [1.4]

ltmain.in in 1.4 has: # On Cygwin there's no real PIC flag so we must build both object types case $host_os in cygwin* | mingw* | pw32* | os2*) pic_mode=default ;; esac Taking a look at the generated libtool on Solaris 8/SPARC and AIX 4.3.2, $host_os is not defined

Re: static/shared libraries on AIX

=== RCS file: /home/cvs/libtool/Attic/ltcf-c.sh,v retrieving revision 1.1.2.36 diff -u -3 -p -r1.1.2.36 ltcf-c.sh --- ltcf-c.sh 2001/04/24 23:58:18 1.1.2.36 +++ ltcf-c.sh 2001/04/26 14:37:37 @@ -268,6 +268,27 @@ else ;; aix4* | aix5*) +if test $host_cpu = ia64

AIX shared libraries in MLB and 1.4

are libfoo.so.o while in 1.4 its libfoo.so.$major. -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: libtool.m4 === RCS file: /home/cvs/libtool/libtool.m4,v retrieving revision 1.166 diff -u -3 -p -r1.166 libtool.m4 --- libtool.m4 2001

Re: AIX shared libraries in MLB and 1.4

different from MLB but I'm assuming you know better what to do). -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

quote.test in 1.4

Why is tests/quote.test hardcoded to use gcc? In MLB tests/quote.test, we use $CC and get CC from tests/defs by: eval `$libtool --config | grep '^CC='` -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http

quote.test in 1.4 and MLB for AIX

;; Any reason we don't define ac_cv_prog_cc_wl='-Wl,' for aix? I think this is the reason quote.test is failing on MLB (because wl= causing libtool to strip -Wl). -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http

Re: AIX shared libraries in MLB and 1.4

). -- albert chin ([EMAIL PROTECTED]) -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: ltconfig.in === RCS file: /home/cvs/libtool/Attic/ltconfig.in,v retrieving revision 1.246.2.58 diff -u -3 -p -r1.246.2.58 ltconfig.in

Re: test if -c and -o work in 1.4

success if the object file was created and has non-empty size? Anyway, if libtool runs and $need_locks=yes, should there be *any* lock files after libtool completes? If so, why don't you add: trap $run $rm $removelist; exit 0 0 to: if test $compiler_c_o = no; then output_obj

Re: static/shared libraries on AIX

as follows: ar cru .libs/libltdl.a ltdl.o ar: 0707-108 File .libs/libltdl.a is not an archive file. AIX is fast catching Ultrix in my league table of `most gratuitously different Unix'... My changes get around this problem in two ways: - When building libtool with run-time-linking

Re: Making hardcode.test more robust [patch against HEAD]

exists? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: 1.3e (1.913) test results for hppa2.0n-hp-hpux11.00 (FAIL)

On Tue, Apr 24, 2001 at 12:46:33AM -0700, Russ Allbery wrote: That patch fixed the hang. The test results still aren't pretty. Apply the fix I posted to libtool-patches. That should bring it down to 6 failures. -- albert chin ([EMAIL PROTECTED

Re: 1.3e (1.910) test results for alpha-dec-osf4.0f (PASS)

On Mon, Apr 23, 2001 at 03:04:37AM -0700, Russ Allbery wrote: There were some warnings during some of the tests, though. Configuring libtool 1.3e (1.910 2001/04/23 00:34:53) checking

Re: 1.3e (1.910) test results for hppa2.0n-hp-hpux11.00 (FAIL)

]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

HP-UX 11.00 and dlopen()

While running ./configure for libtool 1.4 on a hppa1.1-hp-hpux11.00 system: ... checking for dlfcn.h... yes ... checking if libtool supports shared libraries... yes checking for dlopen in -ldl... no checking for dlopen... yes checking whether a program can dlopen itself... yes

Re: HP-UX 11.00 and parsing /bin/nm -p output (failing)

# Write the raw and C identifiers. [lt_cv_sys_global_symbol_pipe=sed -n -e 's/^.*[]\($symcode\)[ ][ ]*\($ac_symprfx\)$sympat$opt_cr$/$symxfrm/p'] So, there can be only *one* $symcode between spaces in the /bin/nm -p output. While creating demo/libtool during a run of 'make tests

Re: Making hardcode.test more robust [patch against HEAD]

is to compile with CFLAGS=-s. Compiling without CFLAGS=-g solves the problem on Solaris and with CFLAGS=-s solves the problem on IRIX 6.x. Good point about host != build. How would I even begin to solve that? -- albert chin ([EMAIL PROTECTED]) ___ Libtool

Re: Libtool and Pkg-Config

by pkg-config could somehow be added to the .la files and libtool could keep track (a registry perhaps) of installed .la files, that would just about cover everything that pkg-config currently does. Some of this data is already in the .la files I believe. Ick! If anything, pkg-config should use

1.4 and hardcode.test on Solaris 2.6 with Sun C

. Compiling without -g fixed things. I'm also failing the *-unst tests but haven't looked into them yet. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool on solaris and hard coding the rpath

On Tue, Mar 13, 2001 at 11:59:28PM -0500, Liam Hoekenga wrote: I'm having problems building numerous packages that were distributed with libtool, in that I can't get libtool to honor any of the -R flags I've set in LDFLAGS. I've seen several messages on this in the archives, but I've

Re: libtool on solaris and hard coding the rpath

On Tue, Mar 13, 2001 at 11:13:24PM -0600, Tim Mooney wrote: In regard to: libtool on solaris and hard coding the rpath, Liam Hoekenga...: % ldd libphp4.so libpam.so.1 = /usr/lib/libpam.so.1 libdl.so.1 =/usr/lib/libdl.so.1 libsocket.so.1 =/usr/lib

Re: Libtool needs -input-file option

On Tue, Feb 20, 2001 at 04:41:03PM -0600, Robert Boehne wrote: I'm busy building a solid modeling library with Libtool and fixing it up along the way. I have found one last barrier, when the command that libtool is invoked with is too large to be read, libtool can't be executed