linking got broken on MacOSX

2007-05-01 Thread Christoph Egger

Hi!

In cvs head, the last change in libltdl/config/ltmain.m4sh
broke linking on MacOSX.

I want to link against -framework ApplicationServices -framework Cocoa 
-framework Carbon

What I get is this:

powerpc-apple-darwin8-gcc-4.0.1: ApplicationServices.ltframework: No such file 
or directory
powerpc-apple-darwin8-gcc-4.0.1: Cocoa.ltframework: No such file or directory
powerpc-apple-darwin8-gcc-4.0.1: Carbon.ltframework: No such file or directory

When I undo the last changes in libltdl/config/ltmain.m4sh, then
linking works.



-- 
Greetings,

Christoph




___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: linking got broken on MacOSX

2007-05-01 Thread Christoph Egger
 Hello Christoph,
 
 * Christoph Egger wrote on Tue, May 01, 2007 at 10:36:29AM CEST:
  
  In cvs head, the last change in libltdl/config/ltmain.m4sh
  broke linking on MacOSX.
 
 Darn.  Thanks for the report.
 
  I want to link against -framework ApplicationServices -framework Cocoa
  -framework Carbon
  
  What I get is this:
  
  powerpc-apple-darwin8-gcc-4.0.1: ApplicationServices.ltframework: No
 such file or directory
  powerpc-apple-darwin8-gcc-4.0.1: Cocoa.ltframework: No such file or
 directory
  powerpc-apple-darwin8-gcc-4.0.1: Carbon.ltframework: No such file or
 directory
  
  When I undo the last changes in libltdl/config/ltmain.m4sh, then
  linking works.
 
 Please post the complete link command line, and all its output,
 with --debug added, and packed (gzip).  Thanks.

Attached.


-- 
Greetings,

Christoph




linking.log.gz
Description: GNU Zip compressed data
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Fix rebuilding rules of ltmain

2007-05-01 Thread Ralf Wildenhues
Hi Gary, and sorry for the delay,

* Gary V. Vaughan wrote on Sat, Apr 28, 2007 at 05:18:09PM CEST:
 On 28 Apr 2007, at 09:04, Ralf Wildenhues wrote:
 
 Repeating the above question: OK to apply?  If not, then ok to revert
 the 2007-03-29, 2007-03-26 changes?
 
 Certainly.  In light of our new found ability to build without GNU  
 make, then applying seems better by far.  Please go ahead.

Thank you.  Applied.

Cheers,
Ralf

* Makefile.am (clean-ltmain-sh): Removed.
(libtool, $(srcdir)/$(m4dir)/ltversion.m4)
($(srcdir)/$(auxdir)/ltmain.sh): Updated to not depend on any
phony rules.  Test `$?' for prerequisites that should always
cause us to update the target.  Fixes rebuilding rules, at the
cost of sometimes updating too much with non-GNU make.




Re: Making shared libraries (DLLs) on Windows: -no-undefined

2007-05-01 Thread Ralf Wildenhues
* Christian Biesinger wrote on Mon, Apr 30, 2007 at 10:40:40PM CEST:
 Brian Dessent wrote:
 So yes, you need to either use -no-undefined unconditionally, or
 conditionalized on PE targets.
 
 What's the point of doing this only on PE targets? Surely the library 
 will either have undefined symbols or not, independent of target... (and 
 note that Windows is not the only platform that needs -no-undefined for 
 shared libraries)

There are/were systems where libtool would use (the equivalent of)
  -Wl,-z -Wl,defs

but where this would hit issues with system libraries.  Compare for
example this comment about some SCO systems, from libtool.m4, which
indicates such a situation (before Libtool changed not to use -z defs
there):

  # Note: We can NOT use -z defs as we might desire, because we do not
  # link with -lc, and that would cause any symbols used from libc to
  # always be unresolved, which means just about no library would
  # ever link correctly.  If we're not using GNU ld we use -z text
  # though, which does catch some bad symbols but isn't as heavy-handed
  # as -z defs.

Generally I think you should be able to just use it everywhere.  The
Libtool testsuite uses it throughout and I cannot remember a test
failure due to it.  I'm however not sure whether there was an issue with
C++ code some time ago (so this data point may be FUD; sorry for not
investigating now).

Hope that helps.

Cheers,
Ralf


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


Re: dll names on windows

2007-05-01 Thread Ralf Wildenhues
Hello Bob, Max, all,

* Bob Rossi wrote on Mon, Apr 30, 2007 at 12:26:25AM CEST:
 On Thu, Apr 19, 2007 at 05:12:49PM -0400, Bob Rossi wrote:
  
  Is there any way that I can have libtool simply create a dll with the
  new 'pcre.dll' instead of 'libpcre-0.dll'? Otherwise, I'll have to code
  into the Makefile some commands to provide the user with what they want.

I think you may be able to hack^Wworkaround like this:
  lib_LTLIBRARIES = pcre.la
  pcre_la_SOURCES = ...
  pcre_la_LDFLAGS = -module

Note though that it's somewhat of a hack, and that I'm not sure whether
it was intended to be (ab)used this way, so maybe I should not recommend
it.  Note also that you cannot build pcre.la and libpcre.la in the same
directory, for namespace collision issues.

Another possibility is to manually copy the file after installation.

 Ping. Maybe this is a stupid question. I'm not really knowledgeable
 enough to know if what I'm asking for doesn't even make sense. I'd like
 to at least find out if it's a reasonable question that I'm asking. :)

Yes, the question is reasonable.  Sorry for the delay.

Cheers,
Ralf


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


Re: Making shared libraries (DLLs) on Windows: -no-undefined

2007-05-01 Thread Simon Richter
Hi,

John Brown wrote:

 I gather that on Linux, you *can* create a shared library with undefined 
 symbols.

Indeed.

 1) Why would anyone do that intentionally?

To link against another library, or to import a symbol defined by the
main program or a library loaded by the main program before. The latter
is heavily discouraged of course, as it is not portable; still a lot of
people do this in their plugin interfaces.

 2) Assuming that it was a mistake, could it happen silently?

Yes, unless -no-undefined is in place.

 3) What are the consequences?

Depending on whether the dynamic linker is in lazy or proactive mode,
the program is terminated when the undefined symbol is first referenced
or when the library is loaded.

Library imports happen quite different on PE platforms, rather than
implicitly through the dynamic linker tables in the objects, there has
to be glue code that explicitly looks up the symbol. Presence of
undefined symbols in a PE object simply means that you forgot to mark a
place where the symbol is referenced as requiring glue code
(__declspec(dllimport)). Also, IIRC this is only possible for C
functions with stdcall ABI (I believe there to be some kludge in Windows
that adjusts the stack for you, but I'm not sure whether that applies to
WNDPROC functions only).

If you set -no-undefined, you are basically saying that your library
does not reference any symbols from objects not listed on the linker
command line, on either platform. As ELF does not care, but PE does,
libtool asks you to state that your code is safe for linking into a PE
shared object.

Hope this helps,
   Simon


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


Re: dll names on windows

2007-05-01 Thread Bob Rossi
On Tue, May 01, 2007 at 10:04:12AM +0200, Ralf Wildenhues wrote:
 Hello Bob, Max, all,
 
 * Bob Rossi wrote on Mon, Apr 30, 2007 at 12:26:25AM CEST:
  On Thu, Apr 19, 2007 at 05:12:49PM -0400, Bob Rossi wrote:
   
   Is there any way that I can have libtool simply create a dll with the
   new 'pcre.dll' instead of 'libpcre-0.dll'? Otherwise, I'll have to code
   into the Makefile some commands to provide the user with what they want.
 
 I think you may be able to hack^Wworkaround like this:
   lib_LTLIBRARIES = pcre.la
   pcre_la_SOURCES = ...
   pcre_la_LDFLAGS = -module

Brain Dessent said I could try the '-avoid-version' switch. It seems to
work. Does that sound good to you?

 Another possibility is to manually copy the file after installation.

Hmm, I hadn't even thought of that. I wasn't sure if copying dll's
worked. That is, I thought maybe the name of the dll was embedded in it
somehow.

  Ping. Maybe this is a stupid question. I'm not really knowledgeable
  enough to know if what I'm asking for doesn't even make sense. I'd like
  to at least find out if it's a reasonable question that I'm asking. :)
 
 Sorry for the delay.

Nonsense! Thanks for the help!

Bob Rossi


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


C flags and headers in a C library

2007-05-01 Thread Joseph Wakeling
Hello,

I'm a novice user of the GNU autotools trying to create the appropriate
configuration for a small simulation library I'm writing, called Minga.

From web tutorials, and examining configure.ac and Makefile.am files in
other free software projects, I've been able to put together something
that appears to allow the library to compile and install but there are a
couple of things that don't work.

First, I'm not sure how to add cflags and library flags to gcc as called
by libtool.  I've tried using AC_SUBST() but the requested flags don't
show up when make is called.  An example of what does show up is,

--
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT minga_version.lo -MD -MP -MF
.deps/minga_version.Tpo -c minga_version.c  -fPIC -DPIC -o
.libs/minga_version.o
--

 when I have been trying to add the flags -ansi -Wall and the
appropriate flags for the GNU Scientific Library (on which my program is
dependent).

Second, I can't work out how to tell the program that it should copy
header files to the $(prefix)/include directory.  Adding an
include_HEADERS line to Makefile.am, for example, results in an error
that there is no rule to build the header files.

I've attached the configure.ac and Makefile.am files to this email and I
wonder if anyone can advise what's wrong?

Thanks for any advice,

-- Joe
AC_INIT([minga],[0.0.1],[EMAIL PROTECTED])
AC_CONFIG_AUX_DIR([build-aux])
AM_INIT_AUTOMAKE([-Wall -Werror foreign])


AC_LANG(C)
AC_PROG_CC
AC_PROG_LIBTOOL

PKG_CHECK_MODULES([DEPS], [gsl = 1.8])
AC_SUBST([DEPS_CFLAGS])
AC_SUBST([DEPS_LIBS])

MINGA_CFLAGS=-ansi -pedantic -Wall

AC_SUBST([MINGA_CFLAGS])

AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile minga/Makefile agents/Makefile anal/Makefile 
error/Makefile games/Makefile])

AC_OUTPUT
MINGA_VERSION_INFO = 0:0:0
SUBDIRS = minga agents anal error games
SUBLIBS = agents/libmingaagents.la anal/libmingaanal.la error/libmingaerror.la 
games/libmingagames.la
#pkginclude_HEADERS = minga_agents.h minga_agent_config.h minga_anal.h 
minga_error.h minga_game.h minga_game_config.h minga_rng.h

pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = minga.pc

lib_LTLIBRARIES = libminga.la
libminga_la_SOURCES = minga_version.c
libminga_la_LIBADD = $(SUBLIBS)
libminga_la_LDFLAGS = -version-info $(MINGA_VERSION_INFO)
___
http://lists.gnu.org/mailman/listinfo/libtool