Including lib.a in lib.so

[François Chenais]

Hello


Using   : ltmain.sh (GNU libtool) 1.3.5 (1.385.2.206 2000/05/27
11:12:27)
Makefile.am : lib_la_LIBADD = /usr/local/lib/lib2.a ./lib.o ...


I would like to make a lib.so library with an other static lib2.a library
but I have 

*** Warning: inter-library dependencies are not known to be supported.
*** All declared inter-library dependencies are being dropped.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

Any idea ??

Thanks a lot

François





-- 
[EMAIL PROTECTED]
   BULL-CITBtel:(+33) 556 437 848   Home: [EMAIL PROTECTED]
207, cours du Médoc fax:(+33) 556 437 978   http://www.citb.bull.net
 33000 Bordeaux BullCom: 227 7848   ICQ :3886291
 Linux
-

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

Win32: Autotools/libtool and MS VC++?

[Marc van Woerkom]

Dear list members,

sadly I have been thrown in the JAVA trenches lately,
(which would lead to the question of JAVA and Autotools :-)
but for now I would need an information regarding Win32.

Using Cygwin and the ported gcc seems supported rather
well (autoconf, automake in the cygwin ports system and libtool 
being able to be compiled form the standard tarball) 
but what happens if one really wants to use the Microsoft
C/C++ compiler?

Leaving out dependencies tracking for a moment (where I was
told to use CVS automake), it was easy to change CC and
CXX variables and flags. But what about library building?
My impression was that libtool has not been extended to
implement its functionality in term of the Microsoft 
compiler. (My problem is that I can't avoid having to 
use that compiler)

Has anyone tried to extend the use of the autotools
and in particular libtool to Microsoft VC++?

If not, could anyone outline how to add it myself?

Regards,
Marc


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

Re: Win32: Autotools/libtool and MS VC++?

[Greg Eisenhauer]

   X-Authentication-Warning: nil.science-factory.com: mvw set sender to 
[EMAIL PROTECTED] using -f
   From: Marc van Woerkom <[EMAIL PROTECTED]>
   Sender: [EMAIL PROTECTED]
   X-BeenThere: [EMAIL PROTECTED]
   X-Mailman-Version: 2.0
   Precedence: bulk
   List-Help: 
   List-Post: 
   List-Subscribe: ,
   
   List-Id: Discussion list for the GNU libtool shared library maintenance tool 

   List-Unsubscribe: ,
   
   List-Archive: 
   Date: Wed, 24 Jan 2001 13:42:02 +0100 (CET)

   Dear list members,

   sadly I have been thrown in the JAVA trenches lately,
   (which would lead to the question of JAVA and Autotools :-)
   but for now I would need an information regarding Win32.

   Using Cygwin and the ported gcc seems supported rather
   well (autoconf, automake in the cygwin ports system and libtool 
   being able to be compiled form the standard tarball) 
   but what happens if one really wants to use the Microsoft
   C/C++ compiler?

   Leaving out dependencies tracking for a moment (where I was
   told to use CVS automake), it was easy to change CC and
   CXX variables and flags. But what about library building?
   My impression was that libtool has not been extended to
   implement its functionality in term of the Microsoft 
   compiler. (My problem is that I can't avoid having to 
   use that compiler)

   Has anyone tried to extend the use of the autotools
   and in particular libtool to Microsoft VC++?

There is support for compiling with VC++ at least in the sense that cygpath
is called to fixup the source file names for the compiler.  However, this
isn't done at the link stage and the path and file names embedded in the
*.la files are Unix-style.  I don't know if the partial cygpath support is
indicative of someone else working on this, but I've been putting a bit of
effort into it myself in the past few days...  I'd like to hear of other
efforts.  Otherwise I'm happy to share my patches when I get things
running... 

greg

-
greg eisenhauer [EMAIL PROTECTED] (404)894-3227
http://www.cc.gatech.edu/~eisen/
College of Computing, Georgia Institute of Technology, Atlanta, GA  30332


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

Re: Win32: Autotools/libtool and MS VC++?

[Olly Betts]

In message <[EMAIL PROTECTED]>, Greg Eisenhauer writes:
>There is support for compiling with VC++ at least in the sense that cygpath
>is called to fixup the source file names for the compiler.  However, this
>isn't done at the link stage and the path and file names embedded in the
>*.la files are Unix-style.  I don't know if the partial cygpath support is
>indicative of someone else working on this, but I've been putting a bit of
>effort into it myself in the past few days...  I'd like to hear of other
>efforts.

My understanding is that MSVC was supported by libtool at some point in the
past, but that the code to handle MSVC hasn't been actively maintained so it
probably no longer works fully.

Cheers,
Olly

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

Re: Win32: Autotools/libtool and MS VC++?

[Morten Eriksen]

Marc van Woerkom <[EMAIL PROTECTED]> writes:

> [...] what happens if one really wants to use the Microsoft C/C++
> compiler?

One solution we've found to work well is to wrap the cl.exe compiler
(and the linker) within a shell script that converts "UNIX-style"
compiler arguments into what MSVC++ expects.

To see our take on how to do that, check out the Coin project at
http://www.coin3d.org>. We've got a MSVC++ script working very
well, and a Borland C++ wrapper script which is not-quite-there.

We even make .dll's with this thing -- but with some hacks. In
general, Autoconf and Automake have all the stuff in place to do a
clean wrapper script for cl.exe, but Libtool doesn't seem to be quite
up to par yet.

I also submitted and got accepted a patch to do dependency tracking
with MSVC++'s cl.exe, so that's already part of the current Automake
CVS.

Regards,
Morten

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

Autoconf 2.49c: Release candidate

[Akim Demaille]

The following message is a courtesy copy of an article
that has been posted to gnu.utils.bug as well.


The Autoconf team is extremely proud (and quite relieved) to announce
the birth of Autoconf 2.49c, our release candidate.  The core Autoconf
is not expected to change before the release, while the documentation
and minor details still need some work.

Since there is a significant number of changes, we would like to ask
maintainers to give a try to this version, so that problems be
identified before the 2.50 release.

Autoconf can be downloaded from

ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.49c.tar.gz

Happy configuring!

Akim, Alexandre, Jim, Pavel, Paul, and Tom.

NEWS:

* Major changes in Autoconf 2.49c   -*- outline -*-

** Lots of bug fixes
Way too many for us to spell them out.  Check out ChangeLog if you
really want to know more.

** Improved documentation
In particular portability issues are better covered.

** Use of Automake
All the standard GNU Makefile targets are supported.  The layout has
changed: m4/ holds the m4 extensions Autoconf needs for its
configuration, doc/ contains the documentation, and tests/ the test
suite.

** Man pages are provided
For autoconf, autoreconf, autoupdate, autoheader, autoscan, ifnames,
config.guess, config.sub.

** autoconf
- --trace
  Provides a safe and powerful means to trace the macro uses.  This
  provide the parsing layer for tools which need to `study'
  configure.in.

- --warnings
  Specify what category of warnings should be enabled.

- When recursing into subdirectories, try for configure.gnu before
  configure to adapt for packages not using autoconf on case-insensitive
  filesystems.

- Diagnostics
  More errors are now caught (circular AC_REQUIRE dependencies,
  AC_DEFINE in the action part of an AC_CACHE_CHECK, too many pops
  etc.).  In addition, their location and call stack are given.

** autoupdate
autoupdate is much more powerful, and is able to provide the glue code
which might be needed to move from an old macro to its newer
equivalent.

You are strongly encouraged to use it both to modernize your
`configure.in', but also your .m4 extension files.

** autoheader
The internal machinery of autoheader has completely changed.  As a
result, using an `acconfig.h' should be considered as obsoleted, and
you are encouraged to get rid of it using the AH macros.

** autoreconf
Deep overhaul.

** Fortran 77 compilers
Globally, the support for Fortran 77 is considerably improved.

Support for automatically determining a Fortran 77 compilers
name-mangling scheme.  New CPP macros F77_FUNC and F77_FUNC_ are
provided to wrap C/C++ identifiers, thus making it easier and more
transparent for C/C++ to call Fortran 77 routines, and Fortran 77 to
call C/C++ routines.  See the Texinfo documentation for details.

** Test suite
The test suite no longer uses DejaGNU.  It should be easy to submit
test cases in this new frame work.

** configure
- --help, --help=long, -hl
  no longer dumps useless items.
- --help=short, -hs
  lists only specific options.
- --help=recursive, -hr
  displays the help of all the embedded packages.
- Remembers environment variables when reconfiguring.
  The previous scheme to set envvar before running configure was
ENV=VAL ./configure
  what prevented configure from remembering the environment in which
  it was run, therefore --recheck was run in an inconsistent
  environment.  Now, one should run
./configure ENV=VAR
  and then --recheck will work properly.  Variables declared with
  AC_ARG_VAR are also preserved.
- cross-compilation
  $build defaults to `config.guess`, $host to $build, and then $target
  to $host.
  Cross-compilation is a global status of the package, it no longer
  depends upon the current language.
  Cross compilation is enabled iff the user specified `--host'.
  `configure' now fails if it can't run the executables it compiles,
  unless cross-compilation is enabled.
- Cache file
  The cache file is disabled by default.  The new options
  `--config-cache', `-C' set the cache to `config.cache'.

** config.status
- faster
  Much faster on most architectures.
- concurrent executions
  It is safe to use `make -j' with config.status.
- human interface improved
  It is possible to invoke
./config.status foobar
  instead of the former form (still valid)
CONFIG_COMMANDS= CONFIG_HEADERS= CONFIG_LINKS= \
CONFIG_FILES=foobar:foo.in:bar.in \
./config.status
  The same holds for configuration headers and links.
  You can instantiate unknown files and headers:
./config.status --header foo.h:foo.h.in --file bar:baz
- has a useful --help


** Identity Macros
- AC_COPYRIGHT
  Specify additional copyright information.

- AC_INIT
  Now expects the identity of the package as argument.

** General changes.
- Uniform quotation
  Most macros, if not all, now strictly follow the `one quotation
  level' rule.  This results in a more predictable expansion.

- AC_REQUIRE
  A sly b

Fix for Arg list too long

[Robert Boehne]

libtoolers:

I have a nice fix for the "Arg list too long" problem but
I need some advice on some parts of the code.

#1)  I have to check for the existence of 'wc -c' to check the
command line length.  The macro can be put into configure.in, but
then if a user doesn't put it there, it won't be used.  It would save
me having to move it and re-submit a patch if I knew where it should go.

#2)  I am checking the system header files to find the maximum command
line length.  Currently I have this in ltconfig.in, but it really
only needs to be run once for each platform, not each tag.  Where should
it go?

#3) $LD is set to $CXX in most cases for C++ compilers, but $reload_cmds
will
not work in general unless $LD is set to 'ld'.  Currently I save the
value
of $LD, set it to "ld$exeext" and restore the value after the
reload_cmds
have been evaluated.  Is there a better way to do this?  It doesn't seem
too nice to hard-code $LD="ld$exeext".

For those of you who are interested, here's how it works:
The command that will be used to create a library is expanded, then
the number of arguments is checked with 'wc -c'.  If the command
is longer than the maximum determined at tag creation time, a separate
block creates reloadable object files using $reload_cmds with
$LD=ld$exeext.
The number of reloadable object files is determined by counting the
number of objects in $libobjs to determine how many can be linked at
once to prevent exceeding the command length limit.  This solution
should have no side effects when it is not used becasue it will
execute as normal if the command line will fit.  It also requires
no porting as it is currently written, and is nearly as fast as it
can be.  A previous design linked objects one at a time, which increased
compile time by orders of magnitude.  Currently it has been tested on
IRIX and OSF1 with Open CASCADE (240Mb of C++ source in 44 shared
libraries).
Testing will continue for Solaris, Linux, HPUX 10.20 & 11.0, and Cygwin
if
I can manage to find a PC with room.

Thanks!

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

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

libtool and MinGW32 toolchain

[stefan]

Hello libtool'ers,
  since the MinGW32 (Minimal GNU for Windows) linker is able to create
shared libraries on Windows I would like to know if it would be posssible
to add support for DLLs to libtool ?
  I do have some knowledge about the general build process on Win32. So if
you want to know how i can tell you...

Thanks in advance,
[EMAIL PROTECTED]


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

CVS libtool 1.4a fails to install

[Bob Friesenhahn]

If GNU make is not named 'make' then the install target fails for the
multi-language-branch:

Making install in libltdl
gmake[1]: Entering directory
`/home/bfriesen/src/gnu/libtool-multilang/libltdl'
Usage : make [ -f makefile ][ -K statefile ]... [ -d ][ -dd ][ -D ][ -DD ]
 [ -e ][ -i ][ -k ][ -n ][ -p ][ -P ][ -q ][ -r ][ -s ][ -S ][ -t ]
 [ -V ][ target... ][ macro=value... ]
make: Fatal error: Unknown option `-w' 

This problem is particularly onerous since the install target should
not normally depend on GNU make.

Installing like 'gmake install MAKE=gmake' works.

The other targets (e.g. 'dist') are also handicapped by this problem.

I prefer to install GNU make as 'gmake' so that it does not shadow the
vendor make program, and makes portability testing easier.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen


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

make distclean fails to remove libltdl/libltdlc.la

[Bob Friesenhahn]

I notice that the distclean target in the libltdl directory fails to
remove libltdlc.la.  This is a bug.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen


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