automake
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]