C++ Shared Libraries
From what I have read about libtool it cannot handle C++ shared libs. Is there any work going on in this area, or should I just do my best with shell scripting in configure.in? Anyone have a better answer? -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]
Support for non-gcc make dependency files
I'd like to have Autoconf generate makefile dependencies for compilers other than gcc, but I'm not familiar with the autoconf source enough to find where it is done. Would someone be kind enough to point me in the right direction? -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ___ Autoconf mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/autoconf
Dependency files not from stdout
I am trying to add support for dependency files that are not sent to standard out. IBM's xl* compilers create dependency information in a file "*.u" with the -M option. The output looks much like what SGI compilers produce. Since it is not sent to stdout, the file would have to be copied to $tmpdepfile and then edited with "tr" like the SGI ouput is. Q1: Is it possible to do this in the current depmod framework? (I think it is, but I'm not sure what the issues from other scripts like libtool are) Q2: How is $depmode set? -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ___ Autoconf mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/autoconf
How do I configure to link to libtcl8.0 or libtcl7.6 depending on what is available?
Dear Autoconfiscaters: I would like to have my package link to whatever version of a package installed, but the names of the library files have the version in the name, i.e. libtcl8.2.so or libtcl75.sl etc. I could read the tcl.h header to get the version numbers, then append that to the library name string, but I want to query more expierenced users in hopes of a better way. Any suggestions? Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]
Re: Auto-tools Win32 Borland C++ Builder
Martin Hollmichel wrote: Hi all, I think the great misunderstanding is that the autotools are not targeting real multiplatform development, but Unix centric distribution of (GNU) OpenSource Software. To do real multiplatform, multitools development the autotools are difficult to use (IHMO). Try to introduce other compilers then (GNU) C, (GNU) C++ Compilers (idl - Compiler, Javac, Resource Compiler, whatever compilers, other dependency generators and you going mad (in my experience). I was often ask why we (I'm responsible for OpenOffice.org build environment on Unix, Windows and Mac platforms) don't use autotools, I say: it's right now not possible and didn't make much sense for really big and multiplatform development). I would like to, but I can't, sorry. A few more examples: * changing a autotool file, then waiting for configure to write 1200 makefiles. * Mixing up debug and non debug build, do both causes double compile time, double diskspace and x-time more RAM for the debugger. Imagine to need 10 GB for Openoffice debug build and more than 2GB RAM to start the result in a debugger. * try to build a four year old glibc on a two year old Linux system or vice versa. You have to begin to hack a configure.in. * using 30 year old preprocessor technology is not the most comfortable way of doing Software Configuration Management (SCM) and script development. 30 year old technology? You mean m4? What do you use? ;) Maybe I'm wrong but is there better bibliography than the info files and GNU Autoconf, Automake and Libtool book by Vaughan, Elliston, Tromey and Taylor? Don't get me wrong, I think the autotools a great tools and I don't want to miss them, but for doing active software development it's not the optimal tool. Anybody who like to give hints to use autotools for OpenOffice.org ? Flame me, Martin Hollmichel Ok Martin, you asked for it! I would venture a guess to say that your project's UNIX build system is either legacy code written before the autotools were a viable option, OR that you don't support most of the Unicies out there. (just a guess) If you were in a position of creating a build system from scratch, and you wanted to keep everything as portable as possible, then there is NO WAY you'd ever decide to do it without Autotools, IMHO. Frankly, every time I see a real project's Makefiles/build system it is far worse than any hacks that might exist in the C source. Projects tend to think of compiling as a secondary issue and portability as somthing they should worry about in C or C++, not make. That doesn't make sense when you think about it, but consider that there are language standards for virtually everything but make's syntax. (correct me if I'm wrong) Now, I'll concede that the GNU autotools don't work perfectly for building under Windows (yet) but that's on the way. The tools are also constantly adding support for different vendor's compilers, I've never seen a patch rejected because it wasn't for gcc, I think everyone's goal is to have a set of tools that work everywhere for every situation. Currently these tools will do the job for 95% of projects on 95% of platforms (or better) and there is nothing else that can claim that. END_FLAME Cheers! Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]
Re: needs help
Toni: Your testers don't need aclocal, autoconf, or automake installed unless they are making changes to Makefile.am or configure.ac. Once you generate configure that's all they need. If someone else's Makefile is running these tools, take it out, it's just plain wrong. The idea of Autoconf is that it creates a portable shell script configure that does all the work. Nothing but the bourne shell is required to generate the Makefiles. Robert Toni Moreno Giménez wrote: Hi to all , I'm new to the list, I have subscribed because i have a little troubles, and I need, help. each time I type make on my project (after doing ./configure ) the Makefile runs another. all autotools system. this is: aclocal autoconf automake ./configure and finally begins the source compilation. is not a big trouble to me. but is it for my betatesters. (they need all auto* tools ) and some times the don't have. I have been looking for ./configure.in in other projects, but i can't find how to disable it. I'm trying to build a first beta release of my project. and I need a lot your help. Lots of thanks. -- = Toni Moreno Giménez = Pje de las rosas nº 22 Vilassar de Mar (Barcelona) Spain CP: 08340 -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]
AC_PROG_SED: rejected?
Hello, I submitted a patch some time ago for adding a macro to autoconf for determining a sed that would truncate the least amount of output (preferring gnu sed also). I haven't seen any discussion of it after my last tweak to the patch, but it hasn't been checked in. I know that the queue can be long, but I just wanted to make sure it wasn't rejected for some reason. Thanks, Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]
Re: seeking advice for a modular build system
There are probably too many to name, but what I played with most recently was FreeTDS on SourceForge which does most of these things. Hans-Christoph Steiner wrote: Do you know of an example of the automake/libtool stuff that you are thinking of? .hc On Mar 10, 2008, at 4:29 PM, [EMAIL PROTECTED] wrote: This shouldn't be much trouble. To enable or disable libraries on the command line you would probably use an Automake conditional, and AC_ARG_WITH to turn it on or off. Automake Libtool together will create generic LDFLAGS as well as library-specific ones automatically. -- Original message -- From: Hans-Christoph Steiner [EMAIL PROTECTED] Hey all, I am starting the process of creating an autotools build system for Pd-extended, a large distro of a program called Pure Data and many libraries. Pure Data is a realtime visual programming language for sound, video, etc. Over the years, there have been quite a few libraries written for it. Currently, I have a big hacked Makefile that builds all of the libraries. I would like to replace this with an autotools system. One thing that I would love to have is flags to ./configure to enable/ disable the inclusion of different libraries. The libraries are currently in subdirs named with the library name. I am wondering how to best to that with autotools. Another thing, each of the libraries are made up of one .so/.dylib/.dll for each objectclass. I am wondering what the best method for having separate CFLAGS and LDFLAGS for each library. I want to do that in case different libraries depend on different versions of the same lib. Perhaps I need some kind of recursive ./ configure system. Thanks in advance! .hc ¡El pueblo unido jamás será vencido! ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: How to determine -rdyamic / -Wl,--export-dynamic flags?
On 03/18/12 17:10, Paul Smith wrote: Does anyone have a macro that will correctly determine when -rdynamic and/or -Wl,--export-dynamic can be used? I'm not using libtool but I'd like my application to be built such that functions in it can be invoked by dynamically loaded objects. I saw http://www.mail-archive.com/autoconf@gnu.org/msg15247.html but there was no definitive response... has anyone come up with something since then? I'd prefer to not invoke a test executable, to preserve cross-compiling. Thanks! Paul, I think you're not getting a response because you're asking a lot. Without testing by running an executable, this can't be determined behaviorally, so your best bet is some sort of lookup. I would suggest you write your own macro, where you set the flag based on known system information, and barring that try some link-time flags and use one that doesn't generate any errors. HTH, Robert ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Dynamic package version numbers with Autoconf and Automake
On 08/15/12 08:45, Bob Friesenhahn wrote: On Wed, 15 Aug 2012, Miles Bader wrote: (3) The final version info is updated (using VCS info and/or autoconf version info) at make time using a script, and when it changes, only causes a source file (e.g., version.c) to change. This means that although some things are rebuilt after a commit (version.o, and relinking of any binaries that use it), the amount of rebuilding is relatively minor while still yielding accurate info. Likewise, GraphicsMagick configures a version.h as well as a version file used for non-autotools builds under Windows. With the currently used mechanism, only the few files depending on version.h need to be rebuilt but the whole project relinks. If the project config.h was to be re-generated (seems to be necessary with new AC_INIT), then all of the source modules would need to be recompiled and relinked since everything depends on the configuration header. Bpb I've had a similar complaint when using Autotest. In my project, the test suite depends on an M4 input file that has the project version encoded in it. cat test_suite/package.m4 # Signature of the current package. m4_define([AT_PACKAGE_NAME], [my_server]) m4_define([AT_PACKAGE_TARNAME], [my_server]) m4_define([AT_PACKAGE_MINOR_VERSION], 4.18) m4_define([AT_PACKAGE_VERSION], [4.18.5]) m4_define([AT_PACKAGE_STRING], [my_server 4.18.5]) Which is created by a makefile rule as suggested in the autoconf documentation: http://www.gnu.org/software/autoconf/manual/autoconf.html#Making-testsuite-Scripts So when I change the version of the package, I autoreconf, then make then autoreconf again. Scenario #2 - I have inherited a library versioning scheme that doesn't play nice with Libtool (an absolute requirement) when the Automake name is not encoded with the version - lib_LTLIBRARIES = libmy_server-4.18.la So every time I change the version argument to AC_INIT, I have to search around my makefiles for anything that references each library and make the same changes there. So I would be very interested in a solution to these issues. Cheers, Robert ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Passing options to libtool from within a GNU Autotools project.
Craig, Just add it to LDFLAGS and it will get added to the link line. If you're building a libtool library: libname_la_LDFLAGS = -preserve-dup-deps or a program prgname_LDFLAGS = -preserve-dup-deps On 11/02/12 08:00, Craig Sanders wrote: Hello all. Does anybody know how to pass additional options to libtool from within a GNU Autotools project? I need to pass the ; --preserve-dup-deps option to libtool from within my Autotools project. I'm not sure if I need to specify this option within my configure.ac file, if it should be specified when I invoke the generated configure script, or how I should otherwise go about it. I'd like to think that I can specify this libtool option from within my configure.ac file, thus relieving any potential users of my package from having to specify this option when they invoke the generated configure script. If anyone can help me out with this matter then it would be greatly appreciated. Thanks in advance for any assistance. _ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
case change in m4_foreach()
I'm writing a macro that takes a list of comma-separated arguments and
then uses m4_foreach
to loop over each argument in the list:
m4_foreach([var_name], [$1]
[
dnl Body
])
In the body I want to do some string manipulation on
the variables value, making it uppercase and replacing - and . with
underscores.
The problem is that for any macro that translates text, the argument
is interpreted literally - i.e.
m4_toupper(var_name)
gives
VAR_NAME
instead of transforming the value, it transforms the name.
i.e.:
#m4_normalize(tl_cxx_DEP)
ds-11.0
#translit(''tl_cxx_DEP'', a-z, A-Z)
''TL_CXX_DEP''
#m4_toupper(tl_cxx_DEP)
TL_CXX_DEP
How can I get the contents of the variable transformed?
Thanks,
Robert Boehne
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: Help with static linking
Statically linking libc is a recipe for disaster, so either read and understand why, or just take my word for it. I don't quite understand why you think you need the rest linked statically, BUT the easiest way to do that would be to add LT_INIT to configure.ac to use Libtool, and add --static-libtool-libs to the target's LDFLAGS. That will cause all of the Libtool libraries to be linked statically when possible. If you are only targeting Linux desktop systems, png, gobject, gio, and glib should already be there, and in most cases already in memory, so you will benefit from zero additional memory use for the code pages. This also goes for all the dependencies of these libraries. I'm not familiar with zzip, so if it isn't a Libtool library you will have to make sure it is linked like this: -Wl,-static -lzzip -Wl,call_shared I don't have a computer in front of me, so YMMV, you should man ld to make sure those flags are correct. HTH, Robert Boehne Kip Warner k...@thevertigo.com wrote: Hey lists, Sorry for posting on both autoconf and automake lists. I wasn't sure which one would be more appropriate for this problem. I know this has come up before, judging by the archives, but I cannot figure out the best way to have my executable statically link against certain dependencies. This is needed because it executes off of optical media and I cannot always guarantee that the user's runtime environment will have the needed dependencies and shipping them shared would be a maintenance nightmare. The dynamic dependencies, according to objdump, are the following... Dynamic Section: NEEDED libgio-2.0.so.0 NEEDED libgobject-2.0.so.0 NEEDED libglib-2.0.so.0 NEEDED libzzip-0.so.13 NEEDED libpng12.so.0 NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libgcc_s.so.1 NEEDED libpthread.so.0 NEEDED libc.so.6 libc, pthreads, the C++ runtime, etc., are safe to assume are available, but the rest I'd like to statically link against. Actually, I'd prefer to statically link against everything that I can if possible. But the ones for certain I know I should be able to statically link against are at least libzzip and libpng. I know there a number of different approaches to doing this, but from the pieces scattered in various places, it was difficult to determine the most reliable and recommended approach. For instance, I've tried 'myproduct_LDADD = $(LIBINTL) -static', but objdump still reports all of the above dynamic dependencies, so maybe it's not doing what I thought it was suppose to do. This is my configure.ac: http://rod.gs/Jwo This is my Makefile.am: http://rod.gs/Lwo Any help appreciated. Respectfully, -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: test for CXXLD
Since the syntax you're using will only support one compiler anyway, you might consider creating a shell script to do the actual configure run. it might look something like this: #!/bin/sh mkdir -p build cd build ../configure --prefix=/path/ferinst --other-arguments LDFLAGS='-Xlinker -languae charm++' Since it's not going to be portable you may as well skip the AM_ variables and go this route. HTH, Robert B On 06/19/13 13:16, Nicolas Bock wrote: Thanks for the reply. I ended up using AM_LDFLAGS = -Xcompiler -language charm++ For some reason CXXLDFLAGS was not added to the linker command in Makefile. Thanks again, nick On Thu, Jun 6, 2013 at 4:40 PM, Gavin Smith gavinsmith0...@gmail.comwrote: On Thu, Jun 6, 2013 at 8:08 PM, Nicolas Bock nicolasb...@gmail.com wrote: Hi, The C++ compiler I am using (charmc) needs an additional command line argument during the linker stage (-language charm++). I am unsure how to best add this argument. The generated makefiles use CXX for compilation and CXXLD for linking, both of which are set to charmc. How would I change CXXLD to add a flag? Or is there a cleaner way to accomplish this? One way would be to pass in the flags on the command line when you invoke make, e.g. make CXXLDFLAGS='-language charm++'. Ideally autoconf would set CXXLD correctly for you but it looks like it this hasn't been implemented for this compiler. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
