Re: Makefile.am assistance
On 10/21/07, Brian Dessent [EMAIL PROTECTED] wrote: Ralf Wildenhues wrote: Well, I could tell you that Libtool can create DLLs plus import libraries (it names them libfoo.dll.a), but I don't think you want to hear that at this point. ;-) Libtool isn't appropriate here because he's not actually building any libraries, only synthesizing import libraries from a .def file for existing binary Microsoft .DLLs. Is there no way to automate that task using built in primaries? Or is the way that I'm doing it the only way to do it?
Re: Makefile.am assistance
On 10/21/07, Ralf Wildenhues [EMAIL PROTECTED] wrote:
* NightStrike wrote on Fri, Oct 19, 2007 at 09:25:08PM CEST:
crt_SCRIPTS = libcrtdll.a libmsvcrt.a libmsvcr80.a
libcrtdll.a libmsvcrt.a libmsvcr80.a:
base=`echo $@ | sed -e 's/\.a//' -e 's/^lib//'`; \
$(DLLTOOL) $(DLLOPTS) --dllname $${base}.dll --def
$(top_srcdir)/$${base}.def
To generate those three libraries, I do nothing other than run
dlltool, passing in the appropriate .def file.
Let's deal with one library only. For the moment, leave Automake out of
the picture, this is a mere issue of how to write 'make' rules.
Am I right in that the input files to dlltool in this case are
foo.dll and foo.def, and the output is the import library libfoo.a?
Sort of. foo.dll is not an actual file.
Then write
libfoo.a: foo.dll foo.def
rule...
for each library. If you can require GNU make (which I guess you can),
then you can write one pattern rule
lib%.a: %.dll %.def
rule...
I sort of did that for the very very long list of .a libs appended to
crt_DATA. I wrote this further down in the makefile:
lib%.a:
$(DLLTOOL) $(DLLOPTS) --def $(top_srcdir)/lib/$*.def
But I didn't know how to adapt that for the extra command to dlltool,
which is '--dllname=foo.dll'
So what I did was the following (committed it as revision 151, too, so
you can see it in the svn repository) :
Index: Makefile.am
===
--- Makefile.am (revision 151)
+++ Makefile.am (working copy)
@@ -36,9 +36,13 @@ dllcrt1.o:
dllcrt2.o:
$(COMPILE) -c $(top_srcdir)/crtdll.c -o $@ -D__MSVCRT__ -U__CRTDLL__
-libcrtdll.a libmsvcrt.a libmsvcr80.a:
- base=`echo $@ | sed -e 's/\.a//' -e 's/^lib//'`; \
- $(DLLTOOL) $(DLLOPTS) --dllname $${base}.dll --def
$(top_srcdir)/$${base}.def
+#libcrtdll.a libmsvcrt.a libmsvcr80.a:
+# base=`echo $@ | sed -e 's/\.a//' -e 's/^lib//'`; \
+# $(DLLTOOL) $(DLLOPTS) --dllname $${base}.dll --def
$(top_srcdir)/$${base}.def
+
+lib%.a: %.def
+ $(DLLTOOL) $(DLLOPTS) --dllname $*.dll --def=$(top_srcdir)/$*.def
+
#libcrtdll.a:
# $(DLLTOOL) --as=$(AS) -k --dllname crtdll.dll --output-lib $@
--def $(top_srcdir)/crtdll.def
#libmsvcrt.a:
Now, however, I have two rules called lib%.a that do different things.
Somehow, make is getting it right, but I have no idea why.
Do you know how to achieve the above effect with using the _LIBRARIES
primary instead of overriding the use of _SCRIPTS?
Well, I could tell you that Libtool can create DLLs plus import
libraries (it names them libfoo.dll.a), but I don't think you want
to hear that at this point. ;-)
I'd love to hear about it. If libtool can do this better, then I'll
use it. I must confess, though, that I couldn't figure it out. It
seemed to require foo.la as output libs instead of foo.a.
Re: Makefile.am assistance
Ralf Wildenhues wrote: Well, I could tell you that Libtool can create DLLs plus import libraries (it names them libfoo.dll.a), but I don't think you want to hear that at this point. ;-) Libtool isn't appropriate here because he's not actually building any libraries, only synthesizing import libraries from a .def file for existing binary Microsoft .DLLs. Brian
Re: Makefile.am assistance
* NightStrike wrote on Fri, Oct 19, 2007 at 09:14:22PM CEST: Should static libraries be executable? They need not be. But it's no problem if they are. Cheers, Ralf
Re: Makefile.am assistance
Why worry about which library files should be executable and which ones are not? Would it be easier to use: foodir=/where/ever foo_LIBRARIES = ... and let the generated Makefile handle getting the permissions right? H
Re: Makefile.am assistance
On 10/19/07, Ralf Wildenhues [EMAIL PROTECTED] wrote: | # These targets require special handling that automake can't | # yet support (or that I don't know how to do properly) | crtdir=$(prefix)/$(target)/lib | crt_SCRIPTS = \ | crt1.o crt2. There is nothing inherently wrong with defining ones own directories. You can even use crt_DATA here, to have mode 644. Note that shared libraries should in general be executable though. Should static libraries be executable?
Re: Makefile.am assistance
NightStrike [EMAIL PROTECTED] writes: Ok. I just tested your idea, and I am going to move all .a custom targets to a _DATA primary, and leave the _SCRIPTS primary for just the custom executable targets (like crt1.o, etc). crt1.o is DATA as well. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Makefile.am assistance
On 10/19/07, Andreas Schwab [EMAIL PROTECTED] wrote: NightStrike [EMAIL PROTECTED] writes: Ok. I just tested your idea, and I am going to move all .a custom targets to a _DATA primary, and leave the _SCRIPTS primary for just the custom executable targets (like crt1.o, etc). crt1.o is DATA as well. Yes, you are right. Apparently, I should be using DATA for everything, and so I am now. I updated the svn repository with the latest version. I am again very open to any comments that people have on how best to do things correctly.
Re: Makefile.am assistance
On 10/19/07, Ralf Wildenhues [EMAIL PROTECTED] wrote: * NightStrike wrote on Fri, Oct 19, 2007 at 09:14:22PM CEST: Should static libraries be executable? They need not be. But it's no problem if they are. Ok. I just tested your idea, and I am going to move all .a custom targets to a _DATA primary, and leave the _SCRIPTS primary for just the custom executable targets (like crt1.o, etc). That's at least a little better. Thanks for the help thus far.
Re: Makefile.am assistance
On 10/19/07, Harlan Stenn [EMAIL PROTECTED] wrote:
Why worry about which library files should be executable and which ones
are not?
Would it be easier to use:
foodir=/where/ever
foo_LIBRARIES = ...
and let the generated Makefile handle getting the permissions right?
For 8 or so of the many many libraries, I do just that. However, I
don't know how to use automake to build a makefile that generates the
bulk of the libraries the way that I need. Observe:
crt_SCRIPTS = libcrtdll.a libmsvcrt.a libmsvcr80.a
libcrtdll.a libmsvcrt.a libmsvcr80.a:
base=`echo $@ | sed -e 's/\.a//' -e 's/^lib//'`; \
$(DLLTOOL) $(DLLOPTS) --dllname $${base}.dll --def
$(top_srcdir)/$${base}.def
To generate those three libraries, I do nothing other than run
dlltool, passing in the appropriate .def file. There is no source
file to speak of, nor any ar or ranlib applied. If I used the
_LIBRARIES primary, the way I understand it is that I would be
required to supply source files (I think), and I could not execute
just dlltool but instead ar and ranlib.
Do you know how to achieve the above effect with using the _LIBRARIES
primary instead of overriding the use of _SCRIPTS?
Re: Makefile.am assistance
ping.. On 10/16/07, NightStrike [EMAIL PROTECTED] wrote: I am trying to build a Makefile.am file correctly. This is what I have so far: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/buildsystem/Makefile.am?revision=137view=markup Some issues that I've noted include installing all libraries as executables instead of 644 (due to using _SCRIPTS for more than its intended purpose) and the install target runs ranlib again for some reason. Does anyone have any suggestions on how to make this a better Makefile.am?
Re: Makefile.am assistance
* NightStrike wrote on Tue, Oct 16, 2007 at 10:42:55PM CEST: I am trying to build a Makefile.am file correctly. This is what I have so far: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/buildsystem/Makefile.am?revision=137view=markup Some issues that I've noted include installing all libraries as executables instead of 644 (due to using _SCRIPTS for more than its intended purpose) and the install target runs ranlib again for some reason. Does anyone have any suggestions on how to make this a better Makefile.am? | # These targets require special handling that automake can't | # yet support (or that I don't know how to do properly) | crtdir=$(prefix)/$(target)/lib | crt_SCRIPTS = \ | crt1.o crt2. There is nothing inherently wrong with defining ones own directories. You can even use crt_DATA here, to have mode 644. Note that shared libraries should in general be executable though. Cheers, Ralf
