[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: program specific LDFLAGS
From: |
David Byron |
Subject: |
RE: program specific LDFLAGS |
Date: |
Sat, 27 Jan 2007 08:35:03 -0800 |
On Saturday, January 27, 2007 @ 7:52a, Ralf Wildenhues wrote:
> Surely writing libfoo.a is a problem when using MSVC + LIB for archive
> creation. But then again that doesn't work well out of the
> box anyway;
> you could be using Libtool, name it libfoo.la and put -static in
> libfoo_la_LDFLAGS.
I'm not using libtool. I am using cccl also the flag doesn't get to the
cccl command line. Yes I do have to jump through some hoops to get .a to
work. Basically I create symlinks to the libraries and then do some magic
inside cccl to make sure that -L finds it. I generally use
-l<path/to/libfoo.a> though.
> > > if PLATFORM_WINDOWS
> > > testrunner_LDADD += $(top_builddir)/minidumper/libminidumper.a
> > > testrunner_LDFLAGS = /ENTRY:testrunnerCRTStartup
> > > LIBS += version.lib
> > > endif
> >
(This part is from Bob Rossi)
> > Again, I would consider doing this very different. In
> > autoconf, figure out if you are on windows with the
> > AC_CANONICAL_TARGET, ..
I could do that, but I think it comes to the same thing in the end. Instead
of /ENTRY in the Makefile, I'd have @address@hidden since this is
used in only one place I figured I'd do it this way.
(Back to Ralf again)
> Actually, I don't see any issue at all with David's very
> first code snippet. And casual inspection shows that it
> seems to be expanded just right by Automake-1.10. David,
> which version do you use?
I use automake 1.10, with your patch to depmod.m4 so .deps is generated
properly. When I went to attach my Makefile.in, I found the problem. I've
gotten in the habit of depending on automake internals to include the build
date/time in my executables...like this:
testrunner_LINK = rm -f $(BUILDINFOFILE);\
echo '\#include <util/buildinfo.h>' >$(BUILDINFOFILE); \
echo >>$(BUILDINFOFILE); \
echo 'const char *BuildInfo = "$(BUILD_INFO)";' >>$(BUILDINFOFILE); \
$(CXXCOMPILE) -c $(BUILDINFOFILE) && \
$(CXXLINK) buildinfo.$(OBJEXT)
There's a thread in the mailing list archives about this:
http://lists.gnu.org/archive/html/automake/2005-11/msg00000.html
Maybe I need to come up with a better way, but this works fine as long as
automake wouldn't otherwise define testrunner_LINK -- when I'm not using
program-specific flags.
It would be nice to be able to do something like this:
save_testrunner_LINK := $(testrunner_LINK)
testrunner_LINK = rm -f $(BUILDINFOFILE);\
echo '\#include <util/buildinfo.h>' >$(BUILDINFOFILE); \
echo >>$(BUILDINFOFILE); \
echo 'const char *BuildInfo = "$(BUILD_INFO)";' >>$(BUILDINFOFILE); \
$(CXXCOMPILE) -c $(BUILDINFOFILE) && \
$(save_testrunner_LINK) buildinfo.$(OBJEXT)
But automake doesn't generate its own testrunner_LINK in this case. I guess
if I'm depending on automake internals, I just have to do it properly which
I guess means diving in even deeper into what automake's testrunner_LINK
would be if I left it alone:
testrunner_LINK = $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) \
$(testrunner_LDFLAGS) $(LDFLAGS) -o $@
Surprise surprise, there's $(testrunner_LDFLAGS), right where it's supposed
to be. Anyway, if I write my build-time-aware replacement of
testrunner_LINK like this:
testrunner_LINK = rm -f $(BUILDINFOFILE);\
echo '\#include <util/buildinfo.h>' >$(BUILDINFOFILE); \
echo >>$(BUILDINFOFILE); \
echo 'const char *BuildInfo = "$(BUILD_INFO)";' >>$(BUILDINFOFILE); \
$(CXXCOMPILE) -c $(BUILDINFOFILE) && \
$(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) $(testrunner_LDFLAGS) $(LDFLAGS) -o $@
buildinfo.$(OBJEXT)
It even seems to work when I don't otherwise define testrunner-specific
flags...I share this recipe with other Makefile's by including an .am file
in each one. So, I guess I'm back to asking if there's a better way than
this to recalculate the date and time only when something else changed, or
just being happy that it's working for now and moving on...
> A small nit (and probably one cause for problems): write
> -ENTRY instead of /ENTRY for MSVC (that's what you're
> after, right?), so the MSYS shell won't mangle it for you.
The /ENTRY (or -ENTRY) flag isn't even getting to a shell. At the moment
I'm using bash on cygwin and cccl + Visual Studio .NET command line tools.
In case anyone does want to use MSYS, I should do as you suggest though.
Thanks for your help.
-DB