Well, I spent the last few days hacking at libtool to get it to use a
staging directory on HP-UX the way I would like. I've include patches
for version 1.5's libtool.m4 and ltmain.in. They include work done by
Ralph Schleicher, Albert Chin, and Martin Frydl in the "libtool
misfeature on HP-UX" thr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zachary Pincus wrote:
| Thanks for your reply, Peter.
|
| I do agree that libtool is behaving correctly here. However, the fact
| remains that this "correct behavior" is causing problems with the motif
| libraries where libXm does indeed depend on libX
On 2004-01-28T15:59-, Scott James Remnant wrote:
) On Wed, 2004-01-28 at 15:15, Daniel Reed wrote:
) > Since there does not appear to be any C++ code (.cc, .cxx, .C) in libtool,
) > would it be possible for the next release of libtool to not:
) There isn't any C code either ... it checks for va
Scott James Remnant wrote:
On Wed, 2004-01-28 at 22:26, Albert Chin wrote:
On Wed, Jan 28, 2004 at 10:13:21PM +, Scott James Remnant wrote:
One day a version of Autoconf will use these, but for now when you run
aclocal it'll add an "m4_include" line to aclocal.m4 for each of these
files (ra
On Wed, 2004-01-28 at 22:26, Albert Chin wrote:
> On Wed, Jan 28, 2004 at 10:13:21PM +, Scott James Remnant wrote:
> > One day a version of Autoconf will use these, but for now when you run
> > aclocal it'll add an "m4_include" line to aclocal.m4 for each of these
> > files (rather than includ
On Wed, Jan 28, 2004 at 10:13:21PM +, Scott James Remnant wrote:
> On Wed, 2004-01-28 at 20:29, Braden McDaniel wrote:
>
> > Why are the libtool macros being installed to $(pkgdatadir) rather than
> > $(datadir)/aclocal?
>
> Because aclocal is slowly being deprecated, and will eventually vani
On Wed, 2004-01-28 at 20:29, Braden McDaniel wrote:
> Why are the libtool macros being installed to $(pkgdatadir) rather than
> $(datadir)/aclocal?
>
Because aclocal is slowly being deprecated, and will eventually vanish
entirely. Managing Autoconf macros really isn't a job for Automake.
The n
Why are the libtool macros being installed to $(pkgdatadir) rather than
$(datadir)/aclocal?
Braden
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Wed, 28 Jan 2004, Andreas Schwab wrote:
> Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> >> [config.log]
> >> configure:5791: /lib/cpp conftest.cc
> >> cpp: conftest.cc: C++ compiler not installed on this system
> >> configure:5797: $? = 1
> >> configure: failed program was:
> >
> > In my opi
On Wed, Jan 28, 2004 at 10:59:32PM +0900, Peter O'Gorman wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Zachary Pincus wrote:
> | Which libtool translates into the following link command:
> | g++ -dynamiclib -single_module -o OUTPUT.dylib [input .o files]
> | /usr/X11R6/lib/libX11.
Scott James Remnant wrote:
On Wed, 2004-01-28 at 14:18, Florian Bachmann wrote:
I am trying to produce a 64bit shared library on a IRIX 6.5 (MIPS4)
machine using the GNU toolchain (gcc, autoconf, automake, libtool).
I am configuring gcc to produce 64bit binaries with CC="gcc -mabi=64".
Libtool co
Thanks for your reply, Peter.
I do agree that libtool is behaving correctly here. However, the fact
remains that this "correct behavior" is causing problems with the motif
libraries where libXm does indeed depend on libX11 and so forth, but
nevertheless, must be on the link line *before* the
Is this a bug or a feature:
I am working on a project that should compile both globally--with prefix
unset so install goes to /usr/local/ and with prefix set to an arbitrary
directory. When the program links, even if I define an -L or an rpath,
it looks to /usr/local/lib for libraries even thou
Alpha Male Plus, the only multiple 0rgasm supplement for men!
Prevent premature ejaculatÃon, become the ultimate sex machine.
Multiple 0rgasms with NO erection loss!
Your easy-to-use solution is here: http://turpsz.us/alpha/?skya
-
Link below is for that people who dislike
adv.
http://tur
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>> [config.log]
>> configure:5791: /lib/cpp conftest.cc
>> cpp: conftest.cc: C++ compiler not installed on this system
>> configure:5797: $? = 1
>> configure: failed program was:
>
> In my opinion, this is the most grevious existing libtool bug. The
>
On Wed, 28 Jan 2004, Daniel Reed wrote:
> On 2004-01-25T14:47-, Scott James Remnant wrote:
> ) The Libtool Team is pleased to announce the release of GNU Libtool
> ) 1.5.2.
>
> Since there does not appear to be any C++ code (.cc, .cxx, .C) in libtool,
> would it be possible for the next releas
On Wed, 2004-01-28 at 15:15, Daniel Reed wrote:
> On 2004-01-25T14:47-, Scott James Remnant wrote:
> ) The Libtool Team is pleased to announce the release of GNU Libtool
> ) 1.5.2.
>
> Since there does not appear to be any C++ code (.cc, .cxx, .C) in libtool,
> would it be possible for the ne
On Wed, 2004-01-28 at 14:18, Florian Bachmann wrote:
> I am trying to produce a 64bit shared library on a IRIX 6.5 (MIPS4)
> machine using the GNU toolchain (gcc, autoconf, automake, libtool).
> I am configuring gcc to produce 64bit binaries with CC="gcc -mabi=64".
> Libtool correctly picks up the
On 2004-01-25T14:47-, Scott James Remnant wrote:
) The Libtool Team is pleased to announce the release of GNU Libtool
) 1.5.2.
Since there does not appear to be any C++ code (.cc, .cxx, .C) in libtool,
would it be possible for the next release of libtool to not:
checking whether ln -s works..
Hi,
I am trying to produce a 64bit shared library on a IRIX 6.5 (MIPS4)
machine using the GNU toolchain (gcc, autoconf, automake, libtool).
I am configuring gcc to produce 64bit binaries with CC="gcc -mabi=64".
Libtool correctly picks up the SGI system linker ("/usr/bin/ld"), but
for some reason i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zachary Pincus wrote:
| Which libtool translates into the following link command:
| g++ -dynamiclib -single_module -o OUTPUT.dylib [input .o files]
| /usr/X11R6/lib/libX11.dylib /usr/X11R6/lib/libXp.dylib
| /usr/X11R6/lib/libXext.dylib /usr/X11R6/lib/
Hello,
I've run across a linking problem with libtool that frankly has me
stymied. (I'm using version 1.5.2, on Mac OS X 10.3, if that matters.)
The general gist is that when libtool automatically decides what
libraries to link in, it can get the link order wrong, which causes
dependency pr
Dano Carroll wrote:
The hello file in /tmp/hello/usr/local/bin/hello is the wrapper file,
not a binary.
I see a very similar problem with an autoconf/automake/libtool project
on HP-UX 11.11 which seems to build and run with no problems in the
staging dir, but when installed into the release dir
23 matches
Mail list logo
