Ralf,
I just tried building lam 7.1.1 with --with-pic passed to configure.
This is insufficient to cause the c source files in liblammpio.a to
be compiled with -fno-common. I'll have to force the use of -fno-common
for now. Forcing the Makefile in lam-7.1.1/romio/adio/common seems
sufficient to
* Ralf Wildenhues wrote on Fri, Nov 18, 2005 at 06:13:00PM CET:
>
> Interix support in Libtool:
Applied missing backport from HEAD to branch-1-5.
Cheers,
Ralf
* ltmain.in (finish mode): Fix a couple of $echo uses.
Reported by Thorsten Glaser <[EMAIL PROTECTED]>.
Index: ltmain.i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christoph Egger on 11/18/2005 7:57 AM:
>>+ (> 2.59) and automake (> 2.9.6).
>>+EOF
>
>
> hmm... I thought automake 1.9.6 is the latest version. Did I miss something?
Nope, just a typo on my part.
- --
Life is short - so eat dessert fi
* Ralf Wildenhues wrote on Fri, Nov 18, 2005 at 06:13:00PM CET:
>
> Interix support in Libtool [...]
Applied to CVS HEAD.
* libtoolize.m4sh (func_copy_all_files)
(func_massage_aclocal_DATA, func_massage_pkgltdl_files)
(func_massage_pkgconfig_files): Work around ksh limita
Libtool Fellas,
This is just a heads-up that I'll be applying the result of the fine
work of Todd Vierling and Thorsten Glaser on Interix support in Libtool:
http://article.gmane.org/gmane.os.miros.general/1406, as soon as the
last minor questions are hashed out, and unless anybody speaks up.
Che
> +$0: This is libtool bootstrap, designed to bootstrap a fresh CVS
> + checkout. Run with reconfdirs=. in the environment to speed up
bootstrap,
> + at the expense of not configuring the testsuite. Run with
> + WORKING_LIBOBJ_SUPPORT=: in the environment if you have a fixed
autoconf
> + (>
Peter,
One other question. Ralf said that they were passing -single_module
for C++ in building shared libs for lam on Darwin. I am correct to
assume that this may have been due to same problem I am seeing...that
a non-PIC static lib was linked into a c++ shared lib? In other words,
like my use
Peter,
Thanks for the reply. I was assuming the solution might be something
along the lines of eliminating the common symbols. I recall when I used
to do a lot of porting of code to linuxppc one of our major problems
was that the intel folks routinely linked static libs into a shared lib
witho
Jack Howarth wrote:
Peter,
One other question. Ralf said that they were passing -single_module
for C++ in building shared libs for lam on Darwin. I am correct to
assume that this may have been due to same problem I am seeing...that
a non-PIC static lib was linked into a c++ shared lib? In ot
Ralf Wildenhues wrote:
Hello everybody,
This topic starts here:
http://www.lam-mpi.org/MailArchives/lam/2005/11/11516.php
http://www.lam-mpi.org/MailArchives/lam/2005/11/11519.php
* Jack Howarth wrote on Fri, Nov 18, 2005 at 05:28:07AM CET:
I found a description of the problem I was seeing
Hello everybody,
This topic starts here:
http://www.lam-mpi.org/MailArchives/lam/2005/11/11516.php
http://www.lam-mpi.org/MailArchives/lam/2005/11/11519.php
* Jack Howarth wrote on Fri, Nov 18, 2005 at 05:28:07AM CET:
> I found a description of the problem I was seeing with the
> mpi enabled
Hi Harald,
Harald Dunkel wrote on Friday, November 18, 2005 11:01 CEST:
> Hi Peter,
>
> Ralf Wildenhues wrote:
> >
> > You may search the archives of the libtool-patches mailing
> list for the
> > dozens of mails Peter Ekberg has written to support all of
> this nicely,
> > including static an
12 matches
Mail list logo
