AW: Linking dynamic AND static with the same lt-libraries
Dear all, thanks for yours replies, I've just forgotten, that I have to repeat some libs in the list. This was one of the reasons to use automake/libtool instead of our old linkerscripts. Kind Regards Thomas Roesner -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Baurzhan Ismagulov Gesendet: Montag, 12. Dezember 2005 22:53 An: automake@gnu.org Betreff: Re: Linking dynamic AND static with the same lt-libraries On Mon, Dec 12, 2005 at 09:28:54AM +0100, Roesner Thomas wrote: > "does not work" means, that the linker can find all refered symbols in > the dynamic scenario, but that there are some unresolved symbols in > the static scenario. As Ralf said, it's most probably the library order, I'd also suggest to check it; if it turns out not to be the case, we'll need the linker output as a starting point. With kind regards, Baurzhan.
Re: release and test targets
Ralf Corsepius wrote: > Baurzhan Ismagulov wrote: > > release: > > $(MAKE) CFLAGS=-O2 prefix=/usr sysconfdir=/etc localstatedir=/var > > You are miss interpreting automake's tasks. Packaging is not of > automake's business. The above technique really has nothing to do with automake and just deals with make by itself. It is obviously just a convenience target. But convenience targets are, well, convenient. I will guess that what you are probably really objecting to, or at least as well, is using the makefile to install things directly into the system's live running directories of /usr and /etc. I see that and it makes me cringe. Much better to use a package manager such as dpkg or rpm for such tasks. I would rather see that trigger a debuild or an rpmbuild and create a real package instead. > Your approach isn't much more but a short-cut to your personal and local > practice and setup. It is wrong and therefore inapplicable almost > anywhere else. I agree it is inapplicable elsewhere. But I disagree it is wrong. If you are the developer and want a short-cut target in your makefile and it does not damage anything else then I believe that would be okay. It adds convenience and removes nothing. There are actually a lot of projects that add local project specific targets to their makefile. Few people outside the project know about it because the public interface of 'tar xzf ...; ./configure; make; make install' all work as expected and they never see the typing aides internal to the development of the project. Bob
Re: Using Automake with shell scripts
You don't have PROGRAMS, you have SCRIPTS. H
Re: Linking dynamic AND static with the same lt-libraries
On Mon, Dec 12, 2005 at 09:28:54AM +0100, Roesner Thomas wrote: > "does not work" means, that the linker can find all refered symbols in > the dynamic scenario, but that there are some unresolved symbols in > the static scenario. As Ralf said, it's most probably the library order, I'd also suggest to check it; if it turns out not to be the case, we'll need the linker output as a starting point. With kind regards, Baurzhan.
Using Automake with shell scripts
I am maintaining a project, GNU Songanizer, which basically consists of a shell script. I am using autoconf/automake to generate the Makefiles by the help of the configure script to maintain GNU compatibility. Hence during installation there is nothing to be compiled. Only the script (ie. bin/songanizer) and the man page (doc/songanizer.1) has to be copied from the bin and doc sub-directories of the installation directory to somewhere like /usr/local/bin and /usr/local/man, etc.. The problem is that if #make install is followed by $make clean, the shell script gets deleted from the bin subdirectory of the extracted tarball. Obviously the problem is because there is no separate source file and executable file as the shell script plays a dual role. How do I write the Makefile.am to avoid this? Following is the Makefile.am in the root installation directory: EXTRA_DIST = AUTHORS ChangeLog COPYING README THANKS SUBDIRS = bin doc MAINTAINERCLEANFILES = Makefile.in configure Following is the Makefile.am in the bin directory: MAINTAINERCLEANFILES = Makefile.in bin_PROGRAMS = songanizer songanizer_SOURCES = songanizer Any help in this regard would be highly appreciated, since I am a newbie with respect to autoconf/automake and reading the postscript documentation has not been able to solve this problem. Thank you, Debarshi Ray
Re: what happens to EXTRA_DIST during distcheck?
> "Ed" == Ed Hartnett <[EMAIL PROTECTED]> writes: Ed> In my top level makefile I have an EXTRA_DIST: Ed> # These files get added to the distribution. Ed> EXTRA_DIST = README COPYRIGHT RELEASE_NOTES Ed> But looking at the _build directory created during make distcheck, I Ed> do not see any of these files: They don't get copied to the build directory. They are put in the final .tar.gz that is the distributable result. Tom
what happens to EXTRA_DIST during distcheck?
Howdy all! In my top level makefile I have an EXTRA_DIST: # These files get added to the distribution. EXTRA_DIST = README COPYRIGHT RELEASE_NOTES But looking at the _build directory created during make distcheck, I do not see any of these files: /shecky/netcdf-3/netcdf-4.0-alpha11/_build: used 472 available 37713960 drwxr-xr-x 14 ed ustaff 4096 Dec 12 08:29 . dr-xr-xr-x 16 ed ustaff 4096 Dec 12 08:28 .. -rw-r--r-- 1 ed ustaff 5178 Dec 12 08:29 config.h -rw-r--r-- 1 ed ustaff 68089 Dec 12 08:29 config.log -rwxr-xr-x 1 ed ustaff 76420 Dec 12 08:29 config.status drwxr-xr-x 4 ed ustaff 4096 Dec 12 08:30 cxx drwxr-xr-x 3 ed ustaff 4096 Dec 12 08:30 f90 drwxr-xr-x 4 ed ustaff 4096 Dec 12 08:29 fortran drwxr-xr-x 4 ed ustaff 4096 Dec 12 08:30 libsrc drwxr-xr-x 4 ed ustaff 4096 Dec 12 08:30 libsrc4 -rwxr-xr-x 1 ed ustaff 223348 Dec 12 08:29 libtool -rw-r--r-- 1 ed ustaff 21383 Dec 12 08:29 Makefile drwxr-xr-x 2 ed ustaff 4096 Dec 12 08:29 man drwxr-xr-x 4 ed ustaff 4096 Dec 12 08:30 ncdump drwxr-xr-x 4 ed ustaff 4096 Dec 12 08:30 ncgen drwxr-xr-x 3 ed ustaff 4096 Dec 12 08:29 nctest drwxr-xr-x 3 ed ustaff 4096 Dec 12 08:29 nc_test drwxr-xr-x 3 ed ustaff 4096 Dec 12 08:29 nc_test4 drwxr-xr-x 3 ed ustaff 4096 Dec 12 08:29 nf_test -rw-r--r-- 1 ed ustaff 23 Dec 12 08:29 stamp-h1 -rw-r--r-- 1 ed ustaff 11 Dec 12 08:28 VERSION Am I missing something here? Thanks! Ed -- Ed Hartnett -- [EMAIL PROTECTED]
Re: AM_CFLAGS not included in translation unit compilation
Hi Mike, * Mike Mattie wrote on Sat, Dec 10, 2005 at 07:24:35PM CET: > On 12/8/05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > * Mike Mattie wrote on Fri, Dec 09, 2005 at 12:59:33AM CET: > > > > > > In a recent project I noticed that the individual compilation units do > > > not include AM_CFLAGS in the invocation of the compiler, however > > > when the program is constructed in the linking phase the AM_CFLAGS > > > variable is used. Is there a rational for this ? I would like > > > to place debugging (-g) in AM_CFLAGS and instead I am placing it in > > > prog_CFLAGS. > > > > Does reading this chapter of the documentation answer your question? > > http://sources.redhat.com/automake/automake.html#Flag-Variables-Ordering > > actually it makes me think even more that my automake (1.9.6) has a > regression against the behavior of previous releases and the > documentation. Depends. I would call it a bugfix rather than a regression. But let's be precise here. Here's a cooked-down version of your issue: touch foo.c bar.c cat >configure.acserver.o is linked from sever-server.o I don't think server.o would ever be used to create sever-server.o. Automake never issues incremental linking rules itself. Maybe you meant server is linked from sever-server.o ? > I think this is clearly wrong. I have a older autotools project from > 2003 where I clearly relied on compiler flags for translation units > being referenced from AM_CFLAGS across the entire > project. Well, I don't see any automake version where it would have worked this way, in that AM_CFLAGS would have been used during compilation. Except for when foo_CFLAGS wasn't supported at all. > If I wished to include flags at the link phase only I would choose > _LDFLAGS after reading the documentation. Yes. AM_CFLAGS and AM_LDFLAGS clearly do have different use though. > I think the above demonstrates that it is not a ordering issue, rather > that a variable that should be included in a compilation is missing > altogether. Do you still think this? > What I need to know is will the upstream maintainers call this one as a bug ? Can't answer that, but I still don't see the way it regresses. Sorry. Cheers, Ralf
Re: Tools under Windows
--- Howard Chu <[EMAIL PROTECTED]> wrote: > Keith MARSHALL wrote: > > BRM wrote: > >> I´ve been playing around with it a bit today, > mostly > >> MSYS, and have thus far only had one issue with > it - > >> cl won´t compile the program because of bad > parameters > >> being passed to it (since MSYS uses // instead of > /). > >> (Not sure if that´s an issue for you guys, > mingw-msys, > >> or the cccl guy; advice appreciated.) > > > > Does MSVC not allow you to use `-' rather than `/' > as the > > switch leader? > Yes, MSVC accepts '-'. Generally Makefiles that were > written for Windows > use slashes, but it's best to convert everything > to dashes. I went > through this exercise for the Mozilla codebase > several months ago... Interesting. When I was playing with it over the weekend, cl wasn't working for some reason, and wouldn't compile my test program under MSYS unless I used a modified cccl to convert the parameters. However, I ran it this morning, and it ran just fine after I removed the '-g' from the CFLAGS in the makefile. Thanks. I've been looking forward to learning autoconf/automake for sometime now, and just now had the opportunity - and I have to support Linux/Unix/Windows at the same time (just made sense). Thanks for the help. Ben TCP/IP Evil-bit RFC ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt
Re: Linking dynamic AND static with the same lt-libraries
* Roesner Thomas wrote on Mon, Dec 12, 2005 at 09:28:54AM CET: > > > On Fri, Dec 09, 2005 at 04:25:42PM +0100, Roesner Thomas wrote: > > > The point is, that I want to build all programs with shared libraries, > > > but one with static libraries, wich are based on the same sourcecode > > > than the shared libraries. Adding "myprog_LDFLAGS = -all-static" does > > > not work. > > > > Could you perhaps elaborate what you mean by "does not work"? > > "does not work" means, that the linker can find all refered symbols in > the dynamic scenario, but that there are some unresolved symbols in > the static scenario. > > Looking in subdir/.libs/mylib.a shows the required symbols in the text > area of the library. The most likely issue is that with static libraries, you need to specify them in the correct order: undefined symbols from libraries early in the command line will, if not yet found in any of the pulled-in objects, be searched only in later objects/libraries. If you libraries depend on one another mutually, you may even have to specify some more than once, and also fiddle with libtool's --preserve-dup-deps. Or there may always be a bug, who knows. In order to be able to say more, you need to show more. For example, a small example that reproduces the issue. Cheers, Ralf
Re: Tools under Windows
Keith MARSHALL wrote: BRM wrote: I´ve been playing around with it a bit today, mostly MSYS, and have thus far only had one issue with it - cl won´t compile the program because of bad parameters being passed to it (since MSYS uses // instead of /). (Not sure if that´s an issue for you guys, mingw-msys, or the cccl guy; advice appreciated.) Does MSVC not allow you to use `-' rather than `/' as the switch leader? Yes, MSVC accepts '-'. Generally Makefiles that were written for Windows use slashes, but it's best to convert everything to dashes. I went through this exercise for the Mozilla codebase several months ago... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Tools under Windows
BRM wrote: > I´ve been playing around with it a bit today, mostly > MSYS, and have thus far only had one issue with it - > cl won´t compile the program because of bad parameters > being passed to it (since MSYS uses // instead of /). > (Not sure if that´s an issue for you guys, mingw-msys, > or the cccl guy; advice appreciated.) Does MSVC not allow you to use `-' rather than `/' as the switch leader? MSYS uses a *leading* `//' to tell its shell that this should be passed to the child program as a literal `/', rather than have it transliterated to backslashes, so the child can recognise Windows style paths -- this is for the benefit of inept MS programs, which refuse to recognise path names using `/' as a directory name separator, in spite of the *native* support for this which is built in to the Windows kernel. Of course, you could avoid this issue entirely, by adopting the MinGW implementation of GCC, instead of MSVC, so that you have an entirely GNU build environment :-) Regards, Keith.
Re: Tools under Windows
Howard Chu wrote, quoting BRM: >> I´m taking a look at Msys/MingW now. Its worked best >> so far - though a script is failing. I got it to run >> by running the VC build environment (e.g. vcvars.bat) >> and then running the msys environment (msys.bat) to >> enter into the msys shell. >> >> Thanks for the tip on cccl. I´ll be sure to look into >> that too; may be its a combination of the two. > > Yes, we use Msys/MinGW for our Windows distributions. I just > added a "call \vcvars.bat" into msys.bat so that gets > set up properly. We also use cccl, although with some > additional customization. Would there be any advantage to you, if I were to add a user customisation hook into the distributed msys.bat, so you wouldn't need to hack your own customisations in, any time you upgrade? (Say, have it call msysite.bat, if it exists in the msys startup directory, just before invoking either rxvt.exe or sh.exe)? Regards, Keith.
Re: shared library from smaller pieces
Hi Vlad, * Vlad Skvortsov wrote on Fri, Dec 09, 2005 at 11:46:46PM CET: > > Ok, I believe I have to explain more here. My product is deemed to be > self-contained: no dependencies on external shared libraries, nothing. I > build all my [C] applications static. However, recently a need has > arised to write a Perl script and include it into the distribution. This > script needs some functionality from my core libraries. So I have to > build a shared module that my Perl script will load and use. I guarantee > that noone else will link against this shared module; if someone will, > it's not my problems, since I didn't intend to. > > My application uses third-party library that is [deemed by its author to > be] built as shared. However, I want all my applications to link > statically against it and I want my shared module to include its > contents (so that the end user doesn't have to install this third-party > shared library). > > Does it make the situation clearer? Yes. The answer is: I don't think this is possible. This isn't even a limitation of the autotools, but simply a limitation of most systems: you can't portably get a shared library to end up being contained in an archive, and the result be used correctly. Somebody please correct me if I'm wrong here, but I would not know that this is doable. The only exceptions I know where this *may* work are w32 and AIX, actually only the latter I believe. > As far as I understand, lib_LIBRARIES and lib_LTLIBRARIES would be > installed into [something like] /usr/local/lib. The non-installed > libraries are created just for convenience during the build process of > the application. Right. > So > 1) linking the application against any lib_LIBRARY and noinst_LIBRARY is > essentially adding objects from that library into the application; > 2) linking the application against any lib_LTLIBRARY will insert > references into the binary; during runtime dunamic linking will be > performed. More or less, yes. > Does using noinst_LTLIBRATIES make sense at all? It is useful to create one larger library from smaller pieces, for example if you use a recursive Makefile structure and your object files are created in several build directories: you could have each Makefile create a convenience archive, and the final step would combine all of these into a lib_LTLIBRARY. So in this sense, it's merely a workaround for packages not using a nonrecursive build. > Or it is supposed to be used by noinst programs only during the > package build (i.e. such as unit tests, etc)? That may be another good use. Although strictly speaking, you are to include convenience archives only into libraries, not into programs. Cheers, Ralf
Linking dynamic AND static with the same lt-libraries
Dear Baurzhan, "does not work" means, that the linker can find all refered symbols in the dynamic scenario, but that there are some unresolved symbols in the static scenario. Looking in subdir/.libs/mylib.a shows the required symbols in the text area of the library. Kind Regards Thomas Roesner -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Baurzhan Ismagulov Gesendet: Freitag, 9. Dezember 2005 22:21 An: automake@gnu.org Betreff: Re: (no subject) Hello Thomas, On Fri, Dec 09, 2005 at 04:25:42PM +0100, Roesner Thomas wrote: > The point is, that I want to build all programs with shared libraries, > but one with static libraries, wich are based on the same sourcecode > than the shared libraries. Adding "myprog_LDFLAGS = -all-static" does > not work. Hmm, works for me. http://ata.cs.hun.edu.tr/~ibr/examples/a.tar.gz: [EMAIL PROTECTED]:/tmp/a$ ldd .libs/a0 a1 .libs/a0: linux-gate.so.1 => (0xe000) liba.so.0 => not found libc.so.6 => /lib/tls/libc.so.6 (0xb7db5000) /lib/ld-linux.so.2 (0xb7f04000) a1: not a dynamic executable Could you perhaps elaborate what you mean by "does not work"? With kind regards, Baurzhan.
