nm now differentiates between weak functions and weak objects
This may be of interest for us. It was installed in Sourceware's
binutils about a month ago. We may need to add V and v to the `nm'
symbol extraction expressions.
2000-01-25 Thomas de Lellis <[EMAIL PROTECTED]>
* syms.c (bfd_decode_symclass)
Two new class characters were added - 'V' and 'v'. The
meaning of 'W' is now restricted to just weak functions.
nm for example now dumps:
'W' = weak global function
'w' = weak unresolved function
'V' = weak global object
'v' = weak unresolved object
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool-2.0
On Feb 26, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> making it relatively similar to bourne shell wouldn't hurt since that
> is already a known quantity, and will be easier for maintainers to get
> to grips with
In fact, if we could keep it fully compatible with (a subset of)
Bourne shell would be great. We might start by using shell functions,
for example. Akim Demaille claims that there's no system in which one
can't find a shell that doesn't support functions, even if that
involves searching for alternatives automatically. In case we can't
find such a shell, we could always make scripts out of the shell
functions, and use them instead.
Then, we could try to use enough of a subset of portable shell with
functions so as to make it easily translatable to portable C. I
believe it can be done, if we factor out enough of the low-level shell
constructs into functions our translator would recognize.
In this case, porting libtool to C, for the benefit of speed, wouldn't
be that painful: it'd be just a matter of writing an appropriate
translator. Not that it would be easy, but it wouldn't require us to
re-implement everything from scratch, and we would just have to keep
in sync the function definitions with their C-based counterparts.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ILD too long
On Feb 14, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
> 2) remove doubled base libraries to libraries.
This can't be done in general. It has already been debated to death
in this mailing list. Please search the archives.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ILD too long
On Feb 14, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>>
>> On Feb 14, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
>>
>> > 2) remove doubled base libraries to libraries.
>> This can't be done in general. It has already been debated to death
>> in this mailing list. Please search the archives.
> I'm very much aware of these discussions. But mine are all -no-undefined
> and that isn't the general case.
Why would -no-undefined make any difference in this case?
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ILD too long
On Feb 15, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>>
>> On Feb 14, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
>>
>> > Alexandre Oliva wrote:
>> >>
>> >> On Feb 14, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
>> >>
>> >> > 2) remove doubled base libraries to libraries.
>>
>> >> This can't be done in general. It has already been debated to death
>> >> in this mailing list. Please search the archives.
>>
>> > I'm very much aware of these discussions. But mine are all -no-undefined
>> > and that isn't the general case.
>>
>> Why would -no-undefined make any difference in this case?
> When I remember right, the discussions were about -la -lb -la
> where they satisfy each other's symbols. You didn't want to
> forbid that, which is ok. But my -lb says it's completly defined,
> so basicly every library libb depends on doesn't make any sense
> _before_ -lb including libb itself.
It does make sense if another, say libx, possibly incomplete, links
with liba too, and pulls symbols from it that are also defined in
libb. If libtool omits the first `-la' in `-lx -la -lb -la', the
executable will get symbols from -lb instead of from -la.
This all assumes -la is a static library. Should it be shared, we
could hopefully drop multiple occurrences thereof, keeping only the
last one.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool 1.3.4 on BeOS doesn't produce shared libs
On Feb 15, 2000, "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> Creating the shared library manually isn't any problem, though:
Look for `-no-undefined' in the libtool manual.
Has the restriction on undefined symbols in BeOS libraries been
lifted?
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ILD too long
On Feb 15, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
>> It does make sense if another, say libx, possibly incomplete, links
>> with liba too, and pulls symbols from it that are also defined in
>> libb. If libtool omits the first `-la' in `-lx -la -lb -la', the
>> executable will get symbols from -lb instead of from -la.
> I don't get it. If libb and liba define the same symbols, static
> linking will fail anyway.
Hmm, I think you're right. It's possible to override a library symbol
when you link an object, but symbol clashes in libraries should result
in hard errors.
> If they define disjunct sets, libx will pull from liba or from libb
> independent of the order. I must miss a point.
No, I did.
In any case, it might be possible, even though extremely unlikely and
of very bad taste, that the symbols of liba that are pulled by libx
depend on libb. In this case, omitting the first occurrence of -la
would cause the symbols in libb to not be resolved.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool 1.3.4 on BeOS doesn't produce shared libs
On Feb 15, 2000, "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> Where would be the correct place to add that option? In src/Makefile.am
> like this?
Yup
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ltconfig decision in creating shared (c++) libraries on solaris.
On Feb 15, 2000, Martin Proulx <[EMAIL PROTECTED]> wrote:
> This choice prevents me from compiling correctly with libtool on
> solaris.
> I have to build a c++ shared library that uses exception.
Libtool doesn't support C++. This is just one of the problems you're
supposed to encounter.
C++ support is under development in the multi-language-branch of the
libtool CVS tree. Feel free to give it a try, and please report any
problems you find.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ltconfig decision in creating shared (c++) libraries on solaris.
On Feb 15, 2000, Martin Proulx <[EMAIL PROTECTED]> wrote:
> I know the support isn't finished, but libtool does work fine with c++
> on my linux box, and it might be partly because on that platform, the
> compiler is used to link.
Yup, g++ with GNU ld works quite well, at least on GNU/Linux and
Solaris. But when you put other compilers or linkers into the
picture, it doesn't get beautiful.
> I believe that if libtool would use g++ to link c++ objects, its would
> have a lot more chances of working correctly than by directly using the
> native linkers.
That's precisely what the branch does. Please give it a try.
> My point was simply that maybe if the GNU compilers on solaris are now
> able to do things correctly
Not always. When libstdc++ is not shared and you try to create a
shared library with g++, it fails. The multi-language libtool works
around the failure.
> that maybe libtool should trust the compiler and use it instead of
> directly using the native compiler because as I have said, using g++
> to link c++ shared libs works correctly.
I wish it were that simple.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: installation of .la-files and linking against installed libraries
On Mar 6, 2000, Assar Westerlund <[EMAIL PROTECTED]> wrote:
> I wrote:
>> "Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
>> > It has been working forever!
An odd use of the word `forever' :-)
> gcc ... -L/usr/local/lib -lbaz
> and does not add the (on this platform) required
> -Wl,-rpath,/usr/local/lib.
> This is libtool 1.3.3 BTW.
Only CVS libtool will implicitly add any necessary -R flags and other
dependencies from the .la file. And that's the reason why this file
is installed.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: installation of .la-files and linking against installed libraries
On Mar 6, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
>> Only CVS libtool will implicitly add any necessary -R flags and other
>> dependencies from the .la file. And that's the reason why this file
>> is installed.
> IIRC, the 1.3b release does this too.
Yup. I forget an alpha release is not just a CVS snapshot :-)
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: [PATCH]: ld/Makefile.am
On Mar 12, 2000, Geoff Keating <[EMAIL PROTECTED]> wrote:
> You want to use exactly the same tools to do the relink as the user
> specified when doing the original link. So you want to use the same
> options, and the same environment variables.
Yup
> All the user has to know is that there's magic going on, but it
> behaves just as if the program was built when libtool was originally
> called.
In fact, the user shouldn't have to know that there's magic going on.
It's supposed to be totally transparent. In this particular case, it
wasn't, and that's why I considered it a bug in libtool and fixed it
there.
Since yesterday, I've also been thinking that we should probably
also save PATH for the relink. Otherwise, a change in the PATH could
cause another compiler driver to be used.
Since that's just a matter of adding one more variable to
variables_saved_for_relink, I won't bother to post a revised patch.
Ok to install?
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: [PATCH]: ld/Makefile.am
On Mar 10, 2000, "H . J . Lu" <[EMAIL PROTECTED]> wrote:
> 1. The new gcc calls collect2.
> 2. collect2 calls ld/ld-new.
> 3. ld/ld-new uses the new gcc to relink the new ld.
No. It's using the old GCC, but it is not using the old linker,
because the environment variables that the external compiler driver
sets up: they shouldn't affect the internal compiler that libtool uses
to re-link the executable, but they do.
I think the right thing to do is to arrange for the libtool
wrapper/relinker script to set GCC_EXEC_PREFIX, COMPILER_PATH and
LIBRARY_PATH to the values they had when the wrapper script was
created, if the compiler in use is GCC.
Here's an (untested, because I have to leave right now) patch that
should fix this problem. I'll make sure a similar (at least in
spirit) patch gets into the libtool CVS tree. The final (i.e., for
libtool) version should probably only save these variables if GCC is
the compiler in use, but this is not strictly necessary, and it won't
hurt to put is in as-is in the Sourceware CVS repo (assuming it
works :-) Ok to install?
H.J., thank you so much for your patience and for helping us figure
out what was the real problem.
Index: ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
* ltmain.sh: Preserve in relink_command any environment variables
that may affect the linker behavior.
Index: ltmain.sh
===
RCS file: /cvs/src/src/ltmain.sh,v
retrieving revision 1.2
diff -u -r1.2 ltmain.sh
--- ltmain.sh 2000/02/27 16:46:19 1.2
+++ ltmain.sh 2000/03/11 22:44:48
@@ -2779,6 +2779,11 @@
# Quote the relink command for shipping.
if test -n "$relink_command"; then
+# Preserve any variables that may affect compiler behavior
+ variables_saved_for_relink="GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
+ for var in $variables_saved_for_relink; do
+ relink_command="$var=\""`eval \$echo \"X'$'$var\" | $Xsed -e "$sed_quote_subst"`"\"; export $var; $relink_command"
+ done
relink_command=`$echo "X$relink_command" | $Xsed -e "$sed_quote_subst"`
fi
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: [PATCH]: ld/Makefile.am
On Mar 13, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 13, 2000 at 02:42:44AM -0300, Alexandre Oliva wrote:
>> I won't bother to post a revised patch. Ok to install?
> Huh? Okay to install what? =)O|
A patch I had posted to binutils only, that fixes the old libtool
version in the binutils source tree.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Multiple interfaces to a single library.
On Mar 19, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> I want to have to [two?] different interfaces into the same library.
You can't do that in a single library, in general. It's a matter of
the linker finding one library expecting a certain interface, and
finding one that doesn't comply with it.
One thing you can do is to split your library into two separate
libraries, one with the more stable interface, whose versions won't
change very often, and another, linked with the first one, with the
unstable interface. So you save those that link with the stable
interface from the instability, without hampering development of the
unstable interface.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Still have linkage problems with libtool
On Mar 20, 2000, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> /bin/sh ./libtool --mode=link gcc -g -O -Wall -Wmissing-prototypes -o
> display display.o magick/libMagick.la
Does libMagick.la (the script) contains both -R flags? What was the
command used to link it?
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Multiple interfaces to a single library.
On Mar 20, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> The current version of libtool's does not support linking to other
> libtool's libraries. Does the current CVS version?
Yep, sorry, forgot to mention that :-(
> How stable is the CVS version?
I've been using it for Kaffe, and others have been using it for other
large projects. It appears to work reasonably well.
> How will this behave with static libraries?
Whenever the second library is linked in, libtool will implicitly link
in any other libraries it depends on. Of course, this assumes people
will be using libtool for linking. If not, they'll have to link in
both libraries explicitly.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool + beos
On Mar 19, 2000, Erik Eriksson <[EMAIL PROTECTED]> wrote:
> # Flag that allows shared libraries with undefined symbols to be built.
> allow_undefined_flag="unsupported"
This used to be true in older releases of BeOS. I'm not sure when the
restriction was lifted, so we need some BeOS expert to tell us, or to
provide a patch that will set allow_undefined_flag appropriately for
all existing releases of BeOS.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool + beos
On Mar 20, 2000, "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> I notice I've hardcoded "deplibs_check_method=pass_all" myself in ltmain.sh
> in some project, because libtool kept dropping the libs my library depend
> on...
It would also be nice to have this defined for BeOS, if it works
properly. But I don't know if it works properly on all releases of
BeOS. Does anybody?
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Multiple interfaces to a single library.
On Mar 21, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> Ok thanks. I think I will try it out. Should I just grab the latest or
> is there a particular branch/date you recommend I try.
The latest should be fine. It hasn't changed much lately, anyway.
> It sounds like using something similar to the *-config (such as
> found with gtk and gnome) scripts would be a good think to use so
> that the end user doesn't have to worry about what to link it.
Indeed. And the *-config script could extract some of the needed
magic from the .la files, but it would not be as trivial as simply
printing `-L$libdir -lchanging -lstable' :-)
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Build problems with SunWorkshop 4.2
On Mar 22, 2000, Christopher Knight <[EMAIL PROTECTED]> wrote:
> While trying to build a shared library that makes use of the STL
> with the SunWorkshop C++ compiler 4.2 on Solaris 2.6, I have found
> the Sun's CC does not work quite right if, when building the shared
> library, .lo files are specified as the objects to link. The compiler
> does not recognize the .lo's as linkable objects and ignores them,
> resulting in undefined symbols.
That's a known problem, and the latest stable release of libtool says
it does not fully support any language other than C. Work towards
supporting other languages is being done by Ossama Othman in the
multi-language branch of the libtool CVS tree. IIRC, this
particularly problem is already fixed there, so you may want to give
it a try.
Please note that multi-language support probably won't be included in
libtool 1.4, only in release 1.5.
> If I manually replace the .lo's on the command line with the corresponding
> .o's, everything works as advertised.
> Therefore, is there a way to force libtool to link the
> .o's rather than .lo's?
--disable-shared will do it, but that's probably not what you had in
mind :-(
> Also, almost everything works after changing all the .lo's to .o's.
Yup. In the multi-language branch, IIRC, the .lo file is placed in
the .libs directory, named `.o', and the .lo file is created as a
wrapper script, just like the .la files.
> However, with Sun's C++ compiler, every STL member of each template
> instantiation becomes a .o file placed in a directory
> named by -ptr (which is passed to both the compiler and the linker).
> (I have been informed that this behavior has now been adopted by ANSI
> and should be appearing in additional C++ compilers in the future)
> To get proper behavior one must build with -ptrdatabase.
Certainly not by ANSI, since the ANSI C++ Standard has not been
reviewed, but it may be part of the C++ ABI specification effort
http://reality.sgi.com/dehnert_engr/cxx/cxx-summary.html
> Below is a minimalistic test taken from my acinclude.m4 file
> to check whether CXXFLAGS needs a -ptr argument.
Thanks. Ossama, can you take care of this, assuming you haven't yet?
BTW, I'm not sure simply testing whether -ptr is accepted by the
compiler is enough. It may be silently accepted by other compilers,
with any random meaning we might think of. We need some test that
verifies that the meaning the one we want. I'm not sure how to
accomplish this, but it would probably involve compiling some piece of
code that makes use of certain STL templates, then a separate
translation unit that works when given the same -ptr flag, but not
when not given it.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Build problems with SunWorkshop 4.2
On Mar 23, 2000, Ossama Othman <[EMAIL PROTECTED]> wrote:
>> Thanks. Ossama, can you take care of this, assuming you haven't yet?
> I haven't. I'll take a look at this.
Thanks. Now I see the sentence above missed a `please', sorry :-(
> Sorry for the silence these past two weeks.
You talk about *your* silence for the past few *weeks*? Come on, I
myself have been mostly silent for the past few *months*! :-)
> This is my academic finals week. :-)
Good luck!
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Build problems with SunWorkshop 4.2
On Mar 23, 2000, Christopher Knight <[EMAIL PROTECTED]> wrote:
> Is there any hack that anyone can think of to switch libtool's usage
> of .lo's to .o's for the time being. I don't really mind if it's a
> huge hack :-), as long as I can get this product building with
> autoconf/automake/libtool...
Well, you can always try to extract the patch that does that from the
multi-language-branch :-)
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Forcing libtool to statically link one library
On Mar 23, 2000, Christopher Knight <[EMAIL PROTECTED]> wrote:
> Any other ideas on forcing statically linking one library?
I'm not sure this can be done portably, but you could try to
explicitly list libname.a (i.e., pick the old_library name from
libname.la)
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Linking static libraries into shared library
On Mar 25, 2000, Jason Day <[EMAIL PROTECTED]> wrote:
> This is what I'll do then. Maybe this could be a future enhancement to
> libtool?
Libtool can't do that in general, since it cannot assume an archive
contains PIC code. However, this gives me an idea: we could have some
mechanism to create an .la file for existing libraries. You'd run
libtool for linking just as usual, but with a flag telling it to not
perform any actual linking, just the creation of the .la files. Then,
it would be trivial to create a convenience library out of an existing
.a file, then use it to create a shared library. But I repeat: this
would only work portably if the archive contained PIC code.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: install-strip
On Mar 27, 2000, "Dirk A. Mueller" <[EMAIL PROTECTED]> wrote:
> would it be possible to add "install-strip" support to libtool?
It's already there, but only in CVS.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Making libtool use c++ to link c++ shared libraries.
On Mar 28, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> How do I make the multi-lang libtool use c++ to link c++ shared libraries
> so that the c++ libraries are linked in.
IIRC, you'd have to arrange for libtool to get an additional
configuration section with information about the C++ compiler. Which,
in configure.in speak, translates to adding a call to AC_LIBTOOL_CXX
:-)
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Making libtool use c++ to link c++ shared libraries.
On Mar 28, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> On 28 Mar 2000, Alexandre Oliva wrote:
> I tried that and it STILL insists on using gcc to make the shared
> libraries.
Do you mean your Makefile runs:
libtool --mode=link g++ lotsastuff.lo -o libmine.la
and, nevertheless, libtool still uses gcc for linking? In this case,
this may be a bug in the recently-added code to automatically select
the most appropriate configuration tag. You may be able to overcome
this problem by explicitly telling libtool which tag to use:
libtool --tag=CXX --mode=link g++ lotsastuff.lo -o libmine.la
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Very reason for not using gcc to link shared libraries?
On Mar 29, 2000, Paul Sokolovsky <[EMAIL PROTECTED]> wrote:
> But what was the problem with gcc in the first place?
The problem was that, since the compiler would implicitly link in
certain libraries, libtool couldn't apply whatever mechanisms it uses
to verify whether the libraries are shared or not, where appropriate.
And this is indeed necessary on some platforms.
Fortunately, thanks mainly to Ossama Othman, this will all be fixed in
libtool 1.5, which is under development in the libtool multi-language
branch. Hopefully, when that work is completed, we'll always be able
to use GCC to link libraries and programs, since libtool will learn
which objects and libraries GCC links in, and will behave as
appropriate.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Re[2]: Very reason for not using gcc to link shared libraries?
On Mar 29, 2000, Paul Sokolovsky <[EMAIL PROTECTED]> wrote:
> What will be next - 1.4 made from MAIN CVS? And next - 1.5 from ML
> CVS?
Yup
> Anyway, if I'm interested in developing libtool, am I suggested to
> look, or maybe even base, on ML branch?
We're trying to get the CVS HEAD stable enough for a release, which
means any major development should be done in the ML branch.
> That's nice. What I'd like to do now is try to make up-to-seamless
> support for win32 dlls. I'm glad to know that there's no problem
> with using gcc to link on *that platform*.
I'm sure Gary will tell you how impossible that is to achieve, because
of the brain-damaged way in which DLLs were designed on MS-Windows.
At least, I think I've already convinced him of that. :-)
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Making libtool use c++ to link c++ shared libraries.
On Mar 29, 2000, "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> This can possibly solve my sub-project linking problem, but autoconf
> complains about not finding AC_LIBTOOL_CXX - where is it?
It's in libtool multi-language branch's libtool.m4
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Making libtool use c++ to link c++ shared libraries.
On Mar 29, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> AC_LIBTOOL_CXX
> AM_PROG_LIBTOOL
You must swap these two lines. AM_PROG_LIBTOOL creates libtool,
AC_LIBTOOL_CXX requires AM_PROG_LIBTOOL, then appends to it, but then
the explicit AM_PROG_LIBTOOL overwrites it. I'll try to fix this.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Re[4]: Very reason for not using gcc to link shared libraries?
On Mar 30, 2000, Paul Sokolovsky <[EMAIL PROTECTED]> wrote:
AO> I'm sure Gary will tell you how impossible that is to achieve, because
AO> of the brain-damaged way in which DLLs were designed on MS-Windows.
> Yes, we already had little talk on this. But that's what ignorant
> newcomers are good for - they don't know precise level of
> impossibility ;-)
Ok, in this case, I won't tell you :-) that the impossibility arises
from the fact that data symbols imported from a DLL must be declared
with __declspec(dllimport), because the code that accesses it must be
generated as if the symbol's type was a pointer its actual type. And,
in the library itself, the symbol must be declared as
__declspec(dllexport), so that the symbol is added to the DLL
relocation table or however they call it.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: assorted problems
On Apr 1, 2000, Erez Zadok <[EMAIL PROTECTED]> wrote:
> and I cannot make dist. I realize why it was done, but I like to be
> able to make my own custom distributions which I unpack on remote
> machines for testing.
I'd rather be safe and avoid ever creating a libtool tarball without
uncommitted changes in ChangeLog, because that's our main
version-control mechanism. You can always run `make dist CVS=:', that
should avoid the problem for you, or install the patch you suggest.
> (2) The config.{sub,guess} distributed in libtool CVS tree are rather old.
> The "common" GNU cvs package is gone. Instead, the newer files are
> distributed from ftp://ftp.gnu.org/pub/gnu/config/
They're usually only upgraded just before a release. There's not much
point in trying to keep them in sync with the master repo. Is there
any particular reason why you think we should upgrade it now, rather
than at release time?
> (3) when running bootstrap, using the latest autoconf/automake, I get
> several of these errors:
Akim is reportedly working on making autoconf more friendly to
``out-of-date'' `configure.in's. Our (my?) intention is to keep
libtool compatible with old versions of autoconf and automake for as
long as possible, so I'd rather not modify configure.in just to
silence these warnings, if this means breaking compatibility with
older auto* tools.
> Making the changes to libtol is pretty simple. I can make them and submit a
> patch if you'd like.
Thanks anyway :-)
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Can't build with cc on Solaris
binutils top-level configure passes --with-gnu-ld down to sub-projects
`configure' commands whenever it finds `ld' is going to be built.
This causes libtool's `configure' fragment and `ltconfig' to search
for GNU ld whenever the compiler is not GCC. If it can't find a GNU
ld, it will just bail out. I currently don't have a solution for this
problem, but one possible work-around is to arrange that the top-level
configure passes `--with-gnu-ld=build' down to sub-projects. I
haven't verified whether this works correctly so far.
The second problem, in the same scenario, is that, when libtool finds
GNU ld, it will assume that the compiler uses it. This assumption is
wrong, and causes an --enable-shared build to break. I've just come
up with a candidate solution for this problem: ltconfig will check
whether the selected compiler actually uses GNU ld. If not, it will
just refrain from using any GNU ld-specific knowledge. This is not
perfect, but it should work for now. I'll try to find some better
solution for libtool 1.4+. Meanwhile, ok to install this one in the
Sourceware CVS tree? In the binutils release branch?
Index: ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
* ltconfig (with_gnu_ld): Check whether the compiler actually uses
GNU ld.
Index: ltconfig
===
RCS file: /cvs/src/src/ltconfig,v
retrieving revision 1.2
diff -u -r1.2 ltconfig
--- ltconfig 2000/02/27 16:46:19 1.2
+++ ltconfig 2000/04/03 05:25:03
@@ -1,7 +1,7 @@
#! /bin/sh
# ltconfig - Create a system-specific libtool.
-# Copyright (C) 1996-1999 Free Software Foundation, Inc.
+# Copyright (C) 1996-2000 Free Software Foundation, Inc.
# Originally by Gordon Matzigkeit <[EMAIL PROTECTED]>, 1996
#
# This file is free software; you can redistribute it and/or modify it
@@ -170,7 +170,7 @@
PROGRAM=ltconfig
PACKAGE=libtool
VERSION=1.3.4
-TIMESTAMP=" (1.385.2.196 1999/12/07 21:47:57)"
+TIMESTAMP=" (1.385.2.196 1999/12/07 21:47:57, modified)"
ac_compile='${CC-cc} -c $CFLAGS $CPPFLAGS conftest.$ac_ext 1>&5'
ac_link='${CC-cc} -o conftest $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS 1>&5'
rm="rm -f"
@@ -1058,6 +1058,27 @@
with_gnu_ld=no
fi
echo "$ac_t$with_gnu_ld" 1>&6
+
+if test "$with_gnu_ld" = yes && test -n "$wl"; then
+ echo $ac_n "checking if the compiler ($CC) uses GNU ld... $ac_c" 1>&6
+ # Check whether this is the linker used by CC, but only if we have
+ # -Wl, or equivalent, otherwise `-v' may be interpreted by the
+ # compiler.
+ "$LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' > conftest.ld
+ rm -f conftest.c
+ echo 'int main() {}' > conftest.c
+ ${CC-cc} -o conftest $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS ${wl}-v 2>&1 |
+ egrep '(GNU|with BFD)' > conftest.ld2
+ if cmp -s conftest.ld conftest.ld2; then
+with_gnu_ld=yes
+ else
+with_gnu_ld=no
+ fi
+ echo "$ac_t$with_gnu_ld" 1>&6
+else
+ # Assume the worst
+ with_gnu_ld=no
+fi
# See if the linker supports building shared libraries.
echo $ac_n "checking whether the linker ($LD) supports shared libraries... $ac_c" 1>&6
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Can't build with cc on Solaris
On Apr 3, 2000, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> From: Alexandre Oliva <[EMAIL PROTECTED]>
>Date: 03 Apr 2000 02:35:33 -0300
>binutils top-level configure passes --with-gnu-ld down to sub-projects
>`configure' commands whenever it finds `ld' is going to be built.
> I think that is a bug.
Agreed. But I believe fixing it won't be enough to get libtool
working; it may still find GNU ld in the PATH and expect cc to use
it, so the patch I posted still applies.
> So I think the correct fix for the binutils is to not pass down
> --with-gnu-ld at all. If we want to continue to support one tree
> builds, then we should only pass --with-gnu-ld to gcc and to
> TARGET_CONFIGDIRS.
I'll try to fix this later on.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: To hack or not to hack
On Apr 4, 2000, Tom Tromey <[EMAIL PROTECTED]> wrote:
Michael> - automake forces me to configure libtool for every package.
Michael> I cannot use a configured libtool installed in a base
Michael> package.
> You might be able to make this work somehow, but I don't know it
> offhand.
I *think* this may work (untested):
define([AC_PROG_LIBTOOL],[
LIBTOOL='$(SHELL) (../)+libtool' # as many `../'s as needed :-)
AC_SUBST(LIBTOOL)
])
AC_PROG_LIBTOOL
I think it would be nice if libtool explicitly supported this kind of
source/build-tree architecture. A macro such as
AC_PROG_LIBTOOL_FROM(../..) would do.
However, you won't be able to use `--enable-shared=pkgname' on
packages that configure libtool like this.
Michael> 2. Is there something else that I can read concerning the
Michael> overall design of these tools?
> For automake, no.
Ditto for libtool.
Michael> 3. Would it be possible for me to have someone to pester
Michael> with questions so that I don't violate some design paradigm
Michael> that would prevent my patches from becoming accepted?
> For automake, ask the list. I won't always have time to answer, but
> other people probably will.
Ditto for libtool :-)
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: AM_ENABLE_SHARED?
On Apr 4, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>>>>>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> I have been using AM_ENABLE_SHARED(no) AM_ENABLE_STATIC(yes)
Bob> AC_PROG_LIBTOOL
> Will probably disappear if you move to AC_, not AM_. Untested.
Why would it disappear? One just `indir's the other.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: 2nd Try: Shared libraries w/ C++ and libltdl
On Apr 10, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote: > About a week ago I posted this massage to the libtool mailing but I have > yet to receive any replies. Sorry. I'm drowning in e-mail :-( Your message was marked as one I should reply some day. Like many hundreds of others :-) > 1) On many platforms libtool can create shared libraries for C but > not for C++ When libtool finds that a shared library depends on a library for which no shared version is available, it decides not to create a static library. This is the only sane thing to do for a module one wouldn't be able to dlopen the module anyway, but maybe we're overdoing it in case of libraries: we might simply drop the dependency library, and expect the final program to be linked with it (assuming allow_undefined, of course). In fact, we might even do it for modules, but this may force the use of libtool to link final programs, and the use of -dlopen to bring in any dependencies that may have been dropped at module-creation time. It would take some work, but would be a good thing to do, IMO. > 2) On many of the platforms which libtool does know how to create > C++ shared libraries libstdc++ is not compiled as a shared library, > nor is it compiled with PIC support. This means that linking the > shared library fails miserably because it will try to link the non > PIC code into the shared library. Libtool should detect whether libstdc++ is available as a shared library or not, and arrange for it to be dropped from the link command in case the shared version is not available, and non-PIC code can't go into shared libraries. In fact, we could improve the test about whether a static library can be linked into a shared one: we could try to create a shared library with references to all symbols exported from the static library. If the link succeeds, it is safe (I think :-) to assume that we don't have to discard the library from the link command. > 1) Is there a way to force libtool NOT to link it as a C++ library if it > can't do it as a shared library. IE don't fall back to only making a > static library. I don't think so. > 2) Is there a way to force libtool NOT to link in libstdc++ but STILL link > it using c++? No, but this can (and should) be improved. > In either case I would like the C++ libraries to be specified in the > .la files so that they will get statically linked in by libtool when > a C program uses my libraries. Which means you'd require the programs to be linked with libtool. Historically, libtool has always avoided being a requirement, but I think it's the only way to offer certain features. > Is they a way to do the ldpreloding stuff that is 100% transparent > to programs linking with my libraries using libtool? I want the end > user to have to doing noting but "libtool --mode=link ... -l library>" and have libtool automatically preload the necessary > modules and set up the data structure automatically so that the end > user does NOT have to call LTDL_SET_PRELOADED_SYMBOLS(). Not really. But there's a lot of room for improvement, with some recent improvements in libltdl. Since now the list of dlopening mechanisms is dynamically modifiable, we could create a symbol table in the module itself, and arrange that, when the module is dlopened, the dlpreopen function performs dlopen(NULL) and looks up a symbol with the name of the symbol table of the library. Assuming dlopen(NULL) works, of course. If it doesn't (and there are situations in which it doesn't), there's not much hope for improvement. Libtool could also try tricks such as setting up dynamic initializers in the object file in which the symbol table is created, that would register dlpreopen handlers in libltdl. But that isn't fully portable either. In any case, we'd still have to make sure that the dlpreopen symbol table gets linked into the final executable, i.e., it would have to be explicitly referenced either in the (shared) library the program is linked with, or in the program itself. One thing you can do is to create your library such that it calls LTDL_SET_PRELOADED_SYMBOLS() in its own initialization function (assuming there is one; if there isn't you may have to call it from all other entry points, or just before any lt_dlopen() called in it). The problem is that you won't be able to declare that library as -no-undefined, so it will be created as a static library on platforms that don't support ``incomplete'' libraries. You'd also have to declare `-dlopen's when you create the library, and hope libtool will propagate these `-dlopen's to the end program. I'm not sure it will; but I'm pretty sure it should :-) You may also have to add `-dlpreopen force' (or however that option is spelled), to make sure that th
Re: 2nd Try: Shared libraries w/ C++ and libltdl
On Apr 11, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>> You're linking C++ libraries to a C program? That seems a bit odd. Did I
>> misunderstand you?
> Why? I have a library that is written in C++ but I would like C
> programs to be able to use my library via extern "C" functions.
> What is so strange about that?
You'll be tying the users of any other programs or libraries going to
be linked together with yours to the same C++ compiler. That's
because `cout' has a difference representation in each compiler, and
each one may try to initialize it assuming its own layout.
It's not clear to me whether this depends on `cout' being used by your
library. I believe the mere fact of having the C++ (shared) library
linked into a program causes `cout' to be initialized.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: 2nd Try: Shared libraries w/ C++ and libltdl
On Apr 11, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> What are you trying to get at. Are you saying that linking C++ libraries
> into a pure C program simply won't work?
It will work as long as the program is pure C. But if it has any
other C++ components (even disguised as libraries with pure-C
interfaces), it may fail.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: 2nd Try: Shared libraries w/ C++ and libltdl
On Apr 12, 2000, Michael Bletzinger <[EMAIL PROTECTED]> wrote:
> I've had some success linking C++ libraries into C using gcc 2.8.1 and
> some of the egcs snapshots on solaris.
Now add a proprietary C++ compiler to the picture :-)
> If you don't want to use libstdc++ then you need to eliminate all
> calls to it including the "<<" and ">>" operators.
I don't think this is enough. If libstdc++ is shared and you link
with it, cin, cout and cerr will be initialized.
> Another option you might to try is listing libstdc++.a as an object
> when you are creating your library.
This may work, as long as you don't pull cin, cout and cerr, nor any
other global variables.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: 2nd Try: Shared libraries w/ C++ and libltdl
On Apr 12, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> On 12 Apr 2000, Alexandre Oliva wrote:
>> On Apr 12, 2000, Michael Bletzinger <[EMAIL PROTECTED]> wrote:
>>
>> > Another option you might to try is listing libstdc++.a as an object
>> > when you are creating your library.
>>
>> This may work, as long as you don't pull cin, cout and cerr, nor any
>> other global variables.
> What about global variables without contractors?
These *may* work :-)
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: 2nd Try: Shared libraries w/ C++ and libltdl
On Apr 12, 2000, Ossama Othman <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 12, 2000 at 07:54:47PM -0400, Kevin Atkinson wrote:
>> On 11 Apr 2000, Alexandre Oliva wrote:
>> > On Apr 10, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>> > > 1) On many platforms libtool can create shared libraries for C but
>> > > not for C++
>> >
>> > When libtool finds that a shared library depends on a library for
>> > which no shared version is available, it decides not to create a
>> > static library.
^^ Oops, I meant `shared' here.
>> > Libtool should detect whether libstdc++ is available as a shared
>> > library or not, and arrange for it to be dropped from the link command
>> > in case the shared version is not available, and non-PIC code can't go
>> > into shared libraries.
>> Yes this would be great. How difficult would it be to implement and how
>> soon do you think it will happen. It would make my life a lot easier.
> This doesn't seem too hard to implement.
Yep. As to when it will happen, but I'm pretty sure it will be when
someone contributes the code :-)
> Alexandre, this feature wouldn't necessarily be specific to the
> multi-language branch, right?
I think it would be easier to put it in there, because that's the only
branch in which libtool analyses the options GCC/g++ uses to call the
linker. It wouldn't even know about libstdc++ in any other case.
>> > > 2) Is there a way to force libtool NOT to link in libstdc++ but STILL link
>> > > it using c++?
>> >
>> > No, but this can (and should) be improved.
>>
>> Actually Ossama Othman told me that using -nostdlib should work At
>> least for gcc
-nostdlib comes with its own bag of problems. IIRC, -nostdlib will
also drop start-files, which means that you'd also get rid of global
initializers and other nice stuff. `-nodefaultlibs -lgcc -lc' would
be far better, but -nodefaultlibs only works in recent releases of
GCC.
> Presumably if libtool was configured with the "-nostdlib" flag passed
> to g++, then libtool won't have any knowledge of libstdc++ at link
> time. I think that Alexandre may have been referring to a way of
> accomplishing the same thing at libtool link time without the
> workaround I described. Alexandre?
Precisely.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Solution to Preload problem & Feature Request
On Apr 13, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> The basic idea is NOT to use the preload feature of libtool but instead
> build up the data structure myself.
Wait a minute. If you're not dlopening anything, you don't need any
preloading. `-dlopen' only applies to modules you're going to dlopen.
> libtool --mode=link-flags -lpspell -lpspell-modules
> would be really great.
> So how about it? How difficult would it be to add that to libtool?
In general, it can't be done. Sometimes libtool has to combine flags,
or to set environment variables, in order to link successfully.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: 2nd Try: Shared libraries w/ C++ and libltdl
On Apr 13, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> On 13 Apr 2000, Alexandre Oliva wrote:
>> On Apr 12, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>>
>> > On 12 Apr 2000, Alexandre Oliva wrote:
>> >> On Apr 12, 2000, Michael Bletzinger <[EMAIL PROTECTED]> wrote:
>> >>
>> >> > Another option you might to try is listing libstdc++.a as an object
>> >> > when you are creating your library.
>> >>
>> >> This may work, as long as you don't pull cin, cout and cerr, nor any
>> >> other global variables.
>>
>> > What about global variables without contractors?
>>
>> These *may* work :-)
> Have you ever seen them NOT work?
Nope, I don't remember having stumbled across any such scenario in a
multi-C++-compiler environment. I myself use only g++.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Solution to Preload problem & Feature Request
On Apr 13, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>> In general, it can't be done. Sometimes libtool has to combine flags,
>> or to set environment variables, in order to link successfully.
> Could you elaborate. When shared libraries are used simply linking with
> -lpspell should work as all the dependences will automatically be tracked
> down provided that the system supports interlibrary dependencies.
Not on all systems.
> If static libraries are used ALL required libraries must be specified on
> the command line. That is what my script will be for.
> What else must be done?
There's the issue of merging -R/-rpath flags, if needed, or setting an
environment variable with them, since on some systems there's no
-R/-rpath flag. More details (lots of them! :-) in the archives.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Solution to Preload problem & Feature Request
On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> If the rpath is not needed or the equivalent will simply listing out the
> necessary libraries work on most, or the most common systems?
If a library depends on another, and you don't explicitly link the
dependency in, the program will fail to link on Solaris, for example.
Is that a common system, in your opinion?
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Solution to Preload problem & Feature Request
On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> On 14 Apr 2000, Alexandre Oliva wrote:
>> On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>>
>> > If the rpath is not needed or the equivalent will simply listing out the
>> > necessary libraries work on most, or the most common systems?
>>
>> If a library depends on another, and you don't explicitly link the
>> dependency in, the program will fail to link on Solaris, for example.
>> Is that a common system, in your opinion?
> I said listing out ALL the required libraries out on the command line when
> linking. Thus the dependency will be linked in?
In this case, it should work.
> Or am I misunderstanding you.
No, I was :-)
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Solution to Preload problem & Feature Request
On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> So will listing out ALL the required libraries, provided that they are in
> the library search path (ie no rpath nonsense) work on most system in both
> the shared and static case?
I hope so :-)
> In the static cast will listing out all libraries along with there
> location (via -L flag) work on most systems?
Ditto
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Solution to Preload problem & Feature Request
On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> Ok, so how difficult would it be to have libtool list out these libraries
> for my "pspell-config" script.
I don't think it would be very hard. It's just a matter of copying
the parts of libtool that expand dependency_libs to the new mode.
> In the case when it won't work, ie rpath is needed, it could print
> out a warning to stderr by still list them out to stdout anyway in
> the case it might just work.
Sounds reasonable.
> I have a felling that others would appreciate this feature also.
My fear is that others might start to depend on this feature, which
might solve the problem for them, but not for people who happen to
install libraries in places other than /usr or /usr/local, like me.
In fact, I've always advocated against these *-config scripts
precisely because they've already caused me a lot of problems in
installations outside /usr.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Solution to Preload problem & Feature Request
On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> Doesn't either setting LD_LIBRARY_PATH (or the equivalent variable for
> your particular system) or adding the weird location to /etc/ld.so.conf
> (or the equivalent file for your particular system) generally solve the
> problem?
It solves it at run-time. But when you're installing programs for
others to use, and you don't want them to have to mess around with any
of those, i.e., you want the programs to ``just work'', this just
doesn't cut it.
> Wouldn't manually infusing the location of the library into
> executables cause problems if the libraries are ever moved?
No. It would only require LD_LIBRARY_PATH or equivalent to be set, or
/etc/ld.so.conf or equivalent (where available) to be modified.
Unless you were to place new libraries where the ones you moved used
to be.
> It would seam to me that it will also make an executable extremely
> non portable across multiple sytems
As long as the multiple systems all mount the directories onto the
same place, it works wonderfully well :-)
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Solution to Preload problem & Feature Request
On Apr 14, 2000, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> Note that since free software is available with full source code, it
> can be compiled to specifically match a particular system
> configuration if an appropriate binary distribuition for that system
> is not available.
As long as the developer doesn't try to impose his view that it is the
user that's responsible for setting LD_LIBRARY_PATH or adding
directories to /etc/ld.so.conf if he doesn't want to follow the
```usual''' set-up.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Solution to Preload problem & Feature Request
On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> I honestly don't see what the hell is wrong with using a shell script to
> do this so a binary can be relocating.
1) You have to figure out whether to use LD_LIBRARY_PATH, SHLIB_PATH,
LD32_LIBRARY_PATH, LD64_LIBRARY_PATH, etc.
2) You have to make sure LD_LIBRARY_PATH won't be overridden by any
search paths that may have been encoded in the executable (on recent
releases of GNU/Linux and FreeBSD, -rpath overrides LD_LIBRARY_PATH,
as demanded by the POSIX Standard)
3) SHLIB_PATH may have been disabled (in fact, it's disabled by
default)
4) IIRC, on some systems, LD_LIBRARY_PATH won't apply to dependent
libraries.
5) etc
6) etc
7) etc :-)
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: missing .deps/dtedio.pp
On May 2, 2000, Ted Irons <[EMAIL PROTECTED]> wrote:
> I am running autoconf-2.13 and automake-1.4
> with the multi-language-branch of libtool on
> an IRIX64-6.5 machine using MIPSpro CC Version 7.2.1.3m.
automake 1.4's dependency tracking mechanism only supports gcc and GNU
make. You'll need a development version of automake to get dependency
tracking to work with other compilers, or you'll have to create your
`Makefile.in's with `automake -i' to disable dependency tracking.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: [PATCH] Re: Problem with ltconfig --mode=link invocation
On Apr 27, 2000, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> ltconfig records for gcc any options from gcc -print-multi-lib and if it
> sees them during --mode link, it passes them into compiler_flags (and thus
> into gcc -shared options)
That's part of what the multi-language branch does.
> In addition to this, it handles -B, -b and -V gcc options.
Which is wrong, because it assumes GCC will be used for linking, while
it won't always be, and you can't just pass -B, -b and -V flags to ld.
That's why libtool currently strips these flags off, and requires the
use of `-Wc,' or `-Wl,' to tell whether to pass flags to the linker or
to the compiler driver. Unfortunately, if ld is used for linking, the
-Wc, flags will never make it to the link command, but there's nothing
that can be done about it. Please try the multi-language branch
before trying to duplicate its work.
> (sparc64-*-linux-gnu*): Use libsuff 64 for search paths.
This is fine. Please post it to [EMAIL PROTECTED], and it will
eventually be installed.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: CVS libtool incompatability with IRIX compiler
On May 3, 2000, Albert Chin-A-Young <[EMAIL PROTECTED]> wrote:
> On Tue, May 02, 2000 at 11:10:32PM +0100, Gary V. Vaughan wrote:
>> On Sat, Apr 22, 2000 at 09:53:42AM -0500, Bob Friesenhahn wrote:
>> This is a known problem with a workaround: when building the libtool
>> compile line, you should use -Wc,-LANG:std
> I don't think it is so simple. The comments below pertain only to IRIX
> C++ 7.3.1.1m. This compiler des not understand -Wc.
It's libtool that understands -Wc, and -Xcompiler and strips them off
when invoking the compiler driver for linking shared libraries.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: CVS libtool incompatability with IRIX compiler
On May 3, 2000, Albert Chin-A-Young <[EMAIL PROTECTED]> wrote:
> Ok, thanks. However, this raises another problem.
> CXXFLAGS="-Wc,-LANG:std" won't work as the configure tests to make
> sure CC works will fail.
You'd have to add this flag to LDFLAGS (since it's only to be used at
link time; at compile-time, -LANG:std is supposed to work), and only
just before outputting the Makefiles in configure.in.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Target for libtool?
On May 6, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> On Sat, May 06, 2000 at 12:35:34AM -0400, Pavel Roskin wrote:
>> It turns out that the following code from libtool.m4 is at fault:
>>
>> case "$target" in
Yup, it's all wrong. Libtool shouldn't care about the target, only
about the host.
>> Question 1. What has Libtool to do with "$target"? Libtool is a wrapper
>> around the compiler doing the build, not being built.
> Libtool needs to know whether the helper binaries it builds need to
> use a native compiler when it is configure to cross compile librarier
> to a different target.
When you use a cross compiler, it means you're building for a
different *host*, not target. The host is the platform on which the
built program is going to run. Build is the platform on which you're
building the program, and target is the platform for which the
compiler being built should generate code. So libtool is only
concerned with host, not target. I wonder how I let this one pass :-(
> If cross compiling to Windows, for example, impgen needs to run
> locally for dlls built for the target host.
When cross compiling to Windows, Windows is the `host'. `target' only
makes sense for the toolchain, and it should never affect the way
libraries are created, because they'll never run on a target platform;
they'll only be created in the build platform and run on the host platform.
>> Question 2. If I'm missing something and more serious modifications are
>> not needed, shouldn't we write the following code instead?
> Looks good to me. I'm committing it now. Thanks.
We'll have to review this code and remove all references to target,
and use host wherever we currently refer to target.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Target for libtool?
On May 8, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> what I said still stands
Yup
>> We'll have to review this code and remove all references to target,
>> and use host wherever we currently refer to target.
> Well volunteered ;')
Yup, it's in my to-do list.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Target for libtool?
On May 9, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>>>>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Hmm. I'm pretty sure autoconf 2.13 set target to "NONE".
> Yes, it did, definitely. But it makes the code much simpler not to
> give a default value. Now, if you think this is the beginning of
> troubles, we might change it back :(
I think I've already seen code that tested whether target = NONE, so
it might be wise to keep it unchanged.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool on Sequent platforms...
On May 17, 2000, Chris Lattner <[EMAIL PROTECTED]> wrote:
> What should I do?
You'd have to change archive_cmds in the appropriate place of
ltconfig. However, I'm not sure whether it's best to run `cc' instead
of `ld' or to add the object files to archive_cmds explicitly. In any
case, this may have to be done as a special case for sequent-sysv4, as
other sysv4s may not work exactly the same.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool passing `-Wl,--whole-archive'
On May 18, 2000, Mocha <[EMAIL PROTECTED]> wrote:
> /bin/sh /usr/pkg/bin/libtool --silent --mode=link gcc -g -O2 -I/usr/pkg/include
Please remove this flag and let us see what libtool prints. For some
reason, it seems to assume it's running GCC for linking, but actually
using ld, so it ``quotes'' the arguments in a way that would cause GCC
to pass them to the linker.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool on Sequent platforms...
On May 18, 2000, Chris Lattner <[EMAIL PROTECTED]> wrote:
> Diffs are against libtool version:
Thanks. We need a ChangeLog entry and a context or unified diff (diff
-c or -u, respectively). Please post them to [EMAIL PROTECTED]
> < archive_cmds='$CC -G -Wl,-h $soname -o $lib $libobjs $deplibs $linkopts'
This assumes GCC. Instead, use `${wl}-h'. You'll probably want
`${wl}' before $soname.
Thanks!
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool passing `-Wl,--whole-archive'
On May 18, 2000, Mocha <[EMAIL PROTECTED]> wrote:
> SYSTEM: NetBSD-1.4Y (-current ELF) on DEC Alpha
> i'm trying to compile PHP4.0RC2 which uses libtool 1.3.4. libtool seems
> to be passing a -Wl to ld which doesn't recognizes it.
Does this patch fix the problem for you?
Index: ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
* ltconfig.in (wlarc): Set to empty on netbsd with GNU ld.
Index: ltconfig.in
===
RCS file: /home/cvs/libtool/ltconfig.in,v
retrieving revision 1.261
diff -u -r1.261 ltconfig.in
--- ltconfig.in 2000/04/10 18:39:30 1.261
+++ ltconfig.in 2000/05/20 08:44:19
@@ -1088,6 +1088,7 @@
archive_expsym_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
else
archive_cmds='$LD -Bshareable $libobjs $deplibs $linker_flags -o $lib'
+ wlarc=
fi
;;
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool passing `-Wl,--whole-archive'
On May 20, 2000, Mocha <[EMAIL PROTECTED]> wrote:
> i tried something similar to this patch.. and it didn't work. but i
> applied yours anyway.. and this is the result..
Try it on libtool 1.3.4. The patch is doing the right thing, but it
seems that the current CVS tree is broken. Or main.lo is not a valid
object file.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool configuration and --build flag
On May 21, 2000, Bram Stolk <[EMAIL PROTECTED]> wrote:
> Why does autoconf put this --build flag in the script, and not in Mesa's
> configure, even though it's the same autoconf version?
As tom said, it's probably an incompatibility between libtool.m4 and
ltconfig. Make sure acinclude.m4 contains the right copy of
libtool.m4.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: BUG? libtool not passing rpath to ld
On May 21, 2000, Mocha <[EMAIL PROTECTED]> wrote:
> does libtool include -rpath's in shared objects?
Not in release 1.3.4. In the CVS tree, there's the hardcode_into_libs
flag that's used to decide whether to do it or not.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: BUG? libtool not passing rpath to ld
On May 22, 2000, Mocha <[EMAIL PROTECTED]> wrote:
> any idea why it's broken in CVS?
Not yet. I haven't had time to investigate yet :-(
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool passing `-Wl,--whole-archive'
On May 20, 2000, Mocha <[EMAIL PROTECTED]> wrote:
> main.lo: file not recognized: File truncated
What's there in main.lo? It should be a valid object file, except
when using the multi-language branch or if libtool was configured with
--disable-shared.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool, Tru64 patches .........
On May 21, 2000, Thomas Leitner <[EMAIL PROTECTED]> wrote:
> + case "$host" in
> + *-*-osf*) if [ "$linkmode" = "lib" ]; then add= ; fi ;;
> + esac
I'd really like to avoid this kind of system-specific kludge in
ltmain. Maybe we can make a configuration variable to enable this behavior?
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: CVS conflict on libtool homepage
On May 24, 2000, Phil Edwards <[EMAIL PROTECTED]> wrote:
> The sidebar on http://www.gnu.org/software/libtool/future.html contains
> a CVS conflict, i.e., there are <<<<< and >>>>> marks visible.
This means one of the GNU webmasters edited the libtool webpages
in-place, instead of editing them over CVS. Could someone at
www.gnu.org please fix it?
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool-1.3.5
On May 26, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> My workload has now eased enough to allow to get back to hacking
> libtool, and I plan to release 1.3.5 this weekend. Is there anything
> pending that I should incorporate into the tree before I roll it up
> and ship it out?
You may want to check in the patches for Sequent and Rhapsody that
have recently been posted to libtool-patches. Since they're ports to
new systems, they can hardly break existing ports :-)
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ML: ltmain.in, improper use of Xsed
On May 28, 2000, Michael Matz <[EMAIL PROTECTED]> wrote:
> Note the "X"s and the doubled \" which shouldn't be there.
Yup, this is definitely wrong, and your fix seems correct. Will you
please post it along with a ChangeLog entry to
[EMAIL PROTECTED]? Thanks in advance.
The other two places you mentioned as suspects appear to be right to
me.
Thanks!
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ltcf-cxx.sh
On May 29, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
> This is a bug in gcc at least til 2.8.1 (no 2.95 here at the
> moment):
> _IO_do_write0x8c
> /opt/GCC281/lib/libstdc++.
> a(stdiostream.o)
Not a bug. It's just that libstdc++ is not PIC, and Solaris' linker
refuses to include such non-PIC code in a shared library. This means
you wouldn't be able to create a shared library with g++ on Solaris.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ltcf-cxx.sh
On May 29, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
> Ossama Othman wrote:
>> Now that I think about it, libtool is only reproducing what the C++
>> compiler would normally do internally, so why would libtool be wrong?
>> Specifically, libtool disables the internal library link commands that
>> the C++ compiler would normally perform automatically, and simply does
>> the linking itself. Why does it work for the C++ compiler?
> It doesn't. This is a bug in gcc at least til 2.8.1 (no 2.95 here at
> the moment):
Which means libtool should consider whether to add libstdc++ (or any
other implicitly-linked libraries, for that matter) just like it
considers any other libraries: on platforms that won't allow non-PIC
code into shared libraries, we'd have to drop it.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ltcf-cxx.sh
On May 26, 2000, Michael Matz <[EMAIL PROTECTED]> wrote:
> On Thu, 25 May 2000, Ossama Othman wrote:
>> Hmm, I though that Alexandre as already took care of this.
Not me, but the patch is already in.
> Hmm, it seems the newest diff to libtool-ml has something, but it
> only deals with stripping an eventual path, the diff below deals
> with that (it also uses CXX not CC, though they should be the same):
BTW, I don't really see the point of using CXX at all. In fact, it's
wrong, we should be consistently using CC.
Would you mind fixing these issues and posting a patch to
[EMAIL PROTECTED], along with a ChangeLog entry?
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ltcf-cxx.sh
On May 29, 2000, Paul Berrevoets <[EMAIL PROTECTED]> wrote:
> In general, this statement is false. The Solaris (>=2.5) linker _does_
> allow non-PIC code in shared libraries.
Ok. The problem is that gcc links shared libraries with `-z text',
unless `-mimpure-text' is given. Maybe that's the flag libtool should
use when it finds libstdc++ is not a shared library.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: test failed
On May 30, 2000, Mocha <[EMAIL PROTECTED]> wrote:
> how can in find out why the test failed and track down the errors.
Start with defining the environment variable VERBOSE, so that you get
more details about the errors.
This might be a symptom of a bug that was fixed yesterday in the CVS
tree, in the test of whether the library format was ELF or a.out.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Parsing nm output on AIX
On May 30, 2000, Linus Nordberg <[EMAIL PROTECTED]> wrote:
> Linus Nordberg <[EMAIL PROTECTED]> wrote
> 26 May 2000 13:22:25 +0200:
>The parsing of /usr/bin/nm output on AIX (at least 4.1.4.0 and
>4.3.2.0) fails.
> Sorry about that. I was using AC_CHECK_TOOL rather than AC_PROG_NM
> (from Libtool) to find `nm' and didn't get the `-B' option.
> What if one really need nm-for-target?
Libtool should probably use AC_CHECK_TOOL itself to find `nm'.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ltcf-cxx.sh
On May 30, 2000, Ossama Othman <[EMAIL PROTECTED]> wrote:
> On Wed, May 31, 2000 at 12:46:34AM -0400, Kevin Atkinson wrote:
>> ltconfig: `./ltcf-gcj.sh' does not exist
>> Not that big of a deal but quite annoying, especially since libtoolize
>> doesn't install it for you.
> Hmm. Alexandre?
Weird... It shouldn't be using this file at all, unless you're using
AC_PROG_GCJ. Maybe I goofed somewhere?
I'll be away until next Friday, so I'd be grateful if someone could
fix this for me.
> Alexandre, Gary, Thomas, which version of Autoconf are you guys
> using?
2.13
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ML branch: okay to switch to CVS automake/autoconf?
On Jun 2, 2000, Ossama Othman <[EMAIL PROTECTED]> wrote:
> I wanted to check with you about switching that branch to use CVS
> autoconf and CVS automake.
Unless there's a very pressing reason to do it, I'd rather be able to
use libtool with older releases of autoconf and automake. I don't
like the idea of forcing people to upgrade more than one tool at a
time, since this makes it harder to figure out where problems that
show up with the upgrades are.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Mixing shared and static libs.
On Jun 2, 2000, Chris <[EMAIL PROTECTED]> wrote:
> I have searched through tons of online info and wonder if anyone else
> has tried to build a shared library that has loaded a static library as
> a dependency? I know this can be done, as I do this all the time.
It can only be done in a few platforms. Libtool 1.3.5 only does that
on a few platforms; libtool 1.4 will do it on a few more platforms,
but, in general, it won't do it, because it's not possible.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ML branch: okay to switch to CVS automake/autoconf?
On Jun 3, 2000, Ossama Othman <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 03, 2000 at 05:52:19PM -0700, Alexandre Oliva wrote:
>> Unless there's a very pressing reason to do it, I'd rather be able to
>> use libtool with older releases of autoconf and automake. I don't
>> like the idea of forcing people to upgrade more than one tool at a
>> time, since this makes it harder to figure out where problems that
>> show up with the upgrades are.
> Okay that's fine. I just thought that most people were using CVS
> Autoconf and Automake. I'll stick with Autoconf 2.13 and Automake
> 1.4.
Actually, it would be great if libtool would work with both stable and
CVS versions of these tools, so that people can use whatever they
prefer. The whole point is to give people the freedom to choose the
version they'd rather use.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: G++ on IRIX and multilang branch
On Jun 15, 2000, [EMAIL PROTECTED] wrote:
> Forgot some -Wl when passing arguments to ld for -update_registry
> under IRIX 6.2 (probably for 6.5 as well).
Looks good to me. Will you please post it to libtool-patches, along
with a ChangeLog entry? TIA,
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Why does libtool still use cc?
On Jul 6, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> Does anyone know why libtool still tries to use cc?
Probably because configure doesn't export CC, and ltconfig performs
its own search for cc, which resembles the original autoconf
AC_PROG_CC implementation.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Why does ltconfig unset CC?
On Jul 9, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> I am trying to understand how libtool configures itself and
> I just can not figure out why ltconfig unsets CC.
This may happen in the second step, when it's looking for a C++ or GCJ
compiler, in case your configure.in mentions CXX or GCJ.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Why does ltconfig unset CC?
On Jul 9, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> On 9 Jul 2000, Alexandre Oliva wrote:
>> On Jul 9, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>>
>> > I am trying to understand how libtool configures itself and
>> > I just can not figure out why ltconfig unsets CC.
>>
>> This may happen in the second step, when it's looking for a C++ or GCJ
>> compiler, in case your configure.in mentions CXX or GCJ.
> If it is looking for g++ or gcj, then why does it end up with cc?
No idea. Never happened to me. Can you post a simple configure.in
file that triggers the problem?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Why does ltconfig unset CC?
On Jul 9, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> appending configuration tag "GCJ" to libtool
Huh? What the hack is GCJ doing here?
> libtool: link: warning: undefined symbols not allowed in
> i386-pc-mingw32msvc shared libraries
RTFM. It will tell you libtool only creates DLLs when you promise
there won't be any undefined symbols (-no-undefined)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Why does ltconfig unset CC?
On Jul 9, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> I don't follow. If this -no-undefined argument needs to be
> passed to libtool, automake should do that.
Nope, automake can't tell whether a library does not depend on any
external symbols. That's something only the developer of the library
can tell.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Why does ltconfig unset CC?
On Jul 10, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> If I want to build a win32 DLL, I indicate this by putting
> AC_LIBTOOL_WIN32_DLL in my configure.in, right?
And promising to libtool that the library is self-contained, which you
do by adding -no-undefined to the command line that creates the
library.
> Does that macro arrange for the correct flags to be passed to
> libtool?
In a sense, it does, because the correct flags are no flags. Whether
a library is self-contained or not must be specified on a per-library
basis. So you have to add -no-undefined to the library's LDFLAGS, but
only if the library is self-contained.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Why does ltconfig unset CC?
On Jul 9, 2000, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Jul 9, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>> appending configuration tag "GCJ" to libtool
> Huh? What the hack is GCJ doing here?
I've just figured it out. Even though your autoconf didn't refer to
GCJ, libtool.m4 did, so aclocal brought automake's AM_PROG_GCJ into
aclocal.m4, but after having copied libtool.m4 there. Since
libtool.m4's hooks were always run, AM_PROG_GCJ would be defined to
[AC_LIBTOOL_GCJ ] before automake's definition. Then, automake's .m4
fragment would:
AC_DEFUN(AM_PROG_GCJ, ...)
without quoting AM_PROG_GCJ, so it would be expanded as previously
defined by libtool, and things would fall from there on.
The failure would have been different if automake defined AM_PROG_GCJ
with proper quoting. OTOH, we might have failed to notice that
AM_PROG_GCJ might not expand AC_LIBTOOL_GCJ for a longer time :-)
Here's a patch that fixes this problem. I'm checking it in right now.
Index: ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
* libtool.m4 (AM_PROG_GCJ): Quote it so that aclocal won't bring
it in if it only appears in libtool.m4.
(AC_PROG_LIBTOOL): Move AC_PROG_CXX, AC_PROG_GCJ and AM_PROG_GCJ
hooks here, so that they can be far simpler!
Index: libtool.m4
===
RCS file: /home/cvs/libtool/libtool.m4,v
retrieving revision 1.71.2.21
diff -u -r1.71.2.21 libtool.m4
--- libtool.m4 2000/06/18 03:02:52 1.71.2.21
+++ libtool.m4 2000/07/10 04:16:50
@@ -22,7 +22,28 @@
## the same distribution terms that you use for the rest of that program.
# serial 45 AC_PROG_LIBTOOL
-AC_DEFUN(AC_PROG_LIBTOOL,[AC_REQUIRE([_AC_PROG_LIBTOOL])])
+AC_DEFUN(AC_PROG_LIBTOOL,[AC_REQUIRE([_AC_PROG_LIBTOOL])
+# If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX
+# immediately, otherwise, hook it in at the end of AC_PROG_CXX.
+ AC_PROVIDE_IFELSE([AC_PROG_CXX],
+[AC_LIBTOOL_CXX],
+[define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX
+])])
+#
+# Quote A][M_PROG_GCJ so that aclocal doesn't bring it in needlessly.
+# If either AC_PROG_GCJ or A][M_PROG_GCJ have already been expanded, run
+# AC_LIBTOOL_GCJ immediately, otherwise, hook it in at the end of both.
+ AC_PROVIDE_IFELSE([AC_PROG_GCJ],
+[AC_LIBTOOL_GCJ],
+[AC_PROVIDE_IFELSE([A][M_PROG_GCJ],
+[AC_LIBTOOL_GCJ],
+ [ifdef([AC_PROG_GCJ],
+ [define([AC_PROG_GCJ], defn([AC_PROG_GCJ])[AC_LIBTOOL_GCJ
+])])#
+ ifdef([A][M_PROG_GCJ],
+ [define([A][M_PROG_GCJ], defn([A][M_PROG_GCJ])[AC_LIBTOOL_GCJ
+])])])])])
+
AC_DEFUN(_AC_PROG_LIBTOOL,
[AC_REQUIRE([AC_LIBTOOL_SETUP])dnl
AC_BEFORE([$0],[AC_LIBTOOL_CXX])dnl
@@ -787,50 +808,6 @@
# clobbered by the next message.
exec 5>>./config.log
])
-
-# If both AC_PROG_CXX and AC_PROG_LIBTOOL have already been expanded,
-# run AC_LIBTOOL_CXX immediately, otherwise, only expand it after the
-# latter of them.
-AC_PROVIDE_IFELSE([AC_PROG_CXX],
-[AC_PROVIDE_IFELSE([AC_PROG_LIBTOOL],
- [AC_LIBTOOL_CXX],
- [define([AC_PROG_LIBTOOL],
- defn([AC_PROG_LIBTOOL])[AC_LIBTOOL_CXX
-])])],
-[define([AC_PROG_CXX],
- defn([AC_PROG_CXX])[AC_PROVIDE_IFELSE([AC_PROG_LIBTOOL],
- [AC_LIBTOOL_CXX],
- [define([AC_PROG_LIBTOOL],
- defn([AC_PROG_LIBTOOL])[AC_LIBTOOL_CXX
-])])])])
-
-# If both A[CM]_PROG_CXX and AC_PROG_LIBTOOL have already been
-# expanded, run AC_LIBTOOL_GCJ immediately, otherwise, only expand it
-# after the latter of them.
-AC_PROVIDE_IFELSE([AC_PROG_GCJ],
-[AC_PROVIDE_IFELSE([AC_PROG_LIBTOOL],
- [AC_LIBTOOL_GCJ],
- [define([AC_PROG_LIBTOOL],
- defn([AC_PROG_LIBTOOL])[AC_LIBTOOL_GCJ
-])])],
-[define([AC_PROG_GCJ],
- defn([AC_PROG_GCJ])[AC_PROVIDE_IFELSE([AC_PROG_LIBTOOL],
- [AC_LIBTOOL_GCJ],
- [define([AC_PROG_LIBTOOL],
- defn([AC_PROG_LIBTOOL])[AC_LIBTOOL_GCJ
-])])])])
-AC_PROVIDE_IFELSE([AM_PROG_GCJ],
-[AC_PROVIDE_IFELSE([AC_PROG_LIBTOOL],
- [AC_LIBTOOL_GCJ],
- [define([AC_PROG_LIBTOOL],
- defn([AC_PROG_LIBTOOL])[AC_LIBTOOL_GCJ
-])])],
-[define([AM_PROG_GCJ],
- defn([AM_PROG_GCJ])[AC_PROVIDE_IFELSE([AC_PROG_LIBTOOL],
- [AC_LIBTOOL_GCJ],
- [define([AC_PROG_LIBTOOL],
- defn([AC_PROG_LIBTOOL])[AC_LIBTOOL_GCJ
-])])])])
dnl old names
AC_DEFUN(AM_PROG_LIBTOOL, [indir([AC_PROG_LIBTOOL])])dnl
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Why does ltconfig unset CC?
On Jul 10, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> dnl This is a hack to work around a bug in autoconf/libtool
> dnl We need to export CC and CC_FOR_BUILD so that libtool
> dnl uses the compiler found by ./configure and we can cross.
I was wrong. ltconfig no longer auto-detects CC, it uses whatever is
passed in from its environment. You don't have to export CC,
AC_PROG_LIBTOOL passes it down to ltconfig.
CC_FOR_BUILD may still be useful, though.
> Now I just need to figure out how to make libtool name it "foo.dll"
> instead of libfoo-0-0-0.dll.
-avoid-version
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: ltcf-cxx.sh
On Jun 3, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> On 3 Jun 2000, Alexandre Oliva wrote:
>> Weird... It shouldn't be using this file at all, unless you're using
>> AC_PROG_GCJ. Maybe I goofed somewhere?
> I actually notice that it not only looks for AC_PROG_GCJ it actually
> configures for it:
Fixed.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: ML libtool: shared libs linked against static ones
On Jun 10, 2000, Ossama Othman <[EMAIL PROTECTED]> wrote:
> Does Solaris actually support linking shared libs against static
> ones?
Yep, but you have to link without the `-z text' flag, that recent GCC
releases pass to the linker. I believe these same release also
support -mimpure-text, to prevent this flag from being passed. At
least, that's the case for gcc 2.6.3 and from 2.8.1 on. Does anybody
have 2.8.0 and 2.7.* on Solaris handy to check? If we find this out
for sure, we'd be able to use pass_all on Solaris, which would be
really great!
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Still having problems with cross nm.
On Jul 5, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> + * libtool.m4 (AC_PROG_NM): Fix macro so that it
> + finds a cross NM on the PATH.
Thanks, please post it to [EMAIL PROTECTED]
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: ltcf-cxx.sh
On May 29, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> Perhaps, but I would prefer an option to either drop the static libraries
> OR get the linker to accept them.
Sounds reasonable to me, on systems in which pass_all works. I wonder
what the default should be... Maybe drop for regular libraries and
not drop for `-module's?
In any case, we'd have to resurrect the shared-library detection
mechanisms on systems for which we've switched to pass_all, and figure
out some way to enable them. And then, implement the option. Any
volunteers?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: BUG? libtool not passing rpath to ld
On May 22, 2000, Mocha <[EMAIL PROTECTED]> wrote:
> I think you may have gotten the Wl (since you made it) into CVS
Yup, just installed.
> but not the
> inter-library dependency one.
Will you please post it to [EMAIL PROTECTED], along with a
ChangeLog entry? Thanks
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: [PATCH] Some inconsistency in collect2, with respect to gcc and libtool
On Jul 10, 2000, Marc Espie <[EMAIL PROTECTED]> wrote:
> What this means is that libtool CAN'T support .lo on any platform
> that relies on collect2 to do its job.
The libtool multi-language branch, which is the only one that claims
to support languages other than C, uses only .o files to name object
files. PIC object files are now stored in the .libs directory, and
the .lo file now is a script that names the PIC and the non-PIC object
files.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
