linking got broken on MacOSX
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
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
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
* 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
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
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
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
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
