Re: split check target into check and test targets

[Baurzhan Ismagulov]

On Tue, Feb 23, 2010 at 04:05:47PM -0800, Daily, Jeff A wrote:
> I attempted to split the "make check" target into "make check" (build
> check_PROGRAMS) and "make test" (run check_PROGRAMS). However, I get
> warnings that check-am was overridden. How might I split the building
> and running of check_PROGRAMS and still use the generated
> parallel-tests using TESTS? Thanks.

There are also these ways:
http://www.opensubscriber.com/message/automake@gnu.org/2136673.html

With kind regards,
-- 
Baurzhan Ismagulov
http://www.kz-easy.com/

Problem of: variable `main_SOURCES' is defined but no program or library has `main' as canonical name (possible typo)

[杨觅]

Hi guys,

I met a strange problem when "automake -a":

core/Makefile.am:3: variable `main_SOURCES' is defined but no program or
core/Makefile.am:3: library has `main' as canonical name (possible typo)

It happens only when generate executable files, as long as I choose to
generate .so lib files, everything is OK.

The system I use is Solaris 10.

Could anybody give me some clue about that?

Thanks a lot!

Bill Yang

Proper way to link Fortran with C++

[Jö Fahlke]

Hi!

Our project uses C++, but some of its optional dependencies require linking
with fortran libraries (like blas).  What is the proper way to do this?

On the one hand the Autoconf documentation says that the output variable FLIBS
should be included after LIBS when linking.  This is consistent with the
documentation for ACX_BLAS from the Autoconf archive, which states

#   To link with BLAS, you should link with:
#
#   $BLAS_LIBS $LIBS $FLIBS
#
#   in that order.

The Automake documentation on the other hand states that I should put $(FLIBS)
into the apropriate _LDADD or _LIBADD variable.  That would include the value
of FLIBS before the value of LIBS on the linker command line, contradicting
the autoconf documentation.

Is there a reason Autconf requires FLIBS after LIBS, and not just FLIBS after
the library actually using fortran?  That would be

   $BLAS_LIBS $FLIBS $LIBS

in the case of blas, and it would allow me to fold FLIBS into BLAS_LIBS.  This
in turn would make it easier to omit the FLIBS completely in case blas was not
detected by configure.

Thanks,
Jö.

-- 
Cernlib: turns your plain old PC into a quantum computer.


signature.asc
Description: Digital signature

create libraries with libtool, but don't install *.la files?

[Andreas Jellinghaus]

Hi,

the combination autoconf/automake/libtool
makes it quite easy to create shared libraries.
but how can I install the file created as a single *.so
file, but without any *.la file etc.

the shared libraries we create implement a fixed plugin
interface thus they don't need the normal versioning
shared libraries have. also applications will only
load the shared libraries using the plugin mechanism,
so neither dynamic not statically linkinging in the
library with application code is required.

can you give an example how to archive this?

Thanks, Andreas

Re: create libraries with libtool, but don't install *.la files?

[Peter Johansson]

Hi,

Andreas Jellinghaus wrote:

Hi,

the combination autoconf/automake/libtool
makes it quite easy to create shared libraries.
but how can I install the file created as a single *.so
file, but without any *.la file etc.

the shared libraries we create implement a fixed plugin
interface thus they don't need the normal versioning
shared libraries have. also applications will only
load the shared libraries using the plugin mechanism,
so neither dynamic not statically linkinging in the
library with application code is required.

can you give an example how to archive this?

  

Wouldn't it work with an install hook such as:

install-exec-hook:
rm -f $(DESTDIR)$(libdir)/libfoo.la

Thanks,
Peter

Automake conditionals in autoconf

[NightStrike]

I'm sending this to both lists because I don't know which one is
right.  I'm trying to conditionally configure and build subdirectories
using Automake conditionals.  I'm flipping back and forth between both
manuals, so I'm guessing both apply.

I have a top level configure/makefile that I'm building to configure
and build the various trees in the mingw-w64.sf.net project.  Here's
the relevant directory layout:

trunk/
trunk/mingw-w64-libraries
trunk/mingw-w64-libraries/libmangle
trunk/mingw-w64-libraries/pseh

trunk contains the top level configure.ac/makefile.am
mingw-w64-libraries contains just sub directories
libmangle and pseh both contain their own self-contained fully
autotool'd build system

This same thing is replicated across a lot of directories inside
trunk, but I'm guessing once I get one right, I'll get them all.

So I have a top level configure, and I put this in it:

AC_MSG_CHECKING([whether to build the optional libraries])
AC_ARG_WITH([libraries],
  [AS_HELP_STRING([--with-libraries=ARG],
[Build the extra mingw-w64 libs, where ARG is one of libmangle,
pseh, or all])],
  [],
  [with_libraries=no])
AS_CASE([$with_libraries],
  [yes|all],[
with_libraries="libmangle,pseh"
with_libraries_mangle=yes
with_libraries_pseh=yes],
  [libmangle],[
with_libraries="libmangle"
with_libraries_mangle=yes
with_libraries_pseh=no],
  [pseh],[
with_libraries="pseh"
with_libraries_mangle=no
with_libraries_pseh=yes],
  [no],[
with_libraries_mangle=no
with_libraries_pseh=no],
  [AC_MSG_ERROR([Invalid argument to --with-libraries: $with_libraries])])
AM_CONDITIONAL([LIBRARIES_MANGLE],[test "x$with_libraries_mangle" = xyes])
AM_CONDITIONAL([LIBRARIES_PSEH],[test "x$with_libraries_pseh" = xyes])
AM_COND_IF([LIBRARIES_MANGLE],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/libmangle])])
AM_COND_IF([LIBRARIES_PSEH],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/pseh])])
AC_MSG_RESULT([$with_libraries])


Those two AM_COND_IF lines at the bottom didn't use to be there.
Instead, I had the AC_CONFIG_SUBDIRS lines in each appropriate branch
of the case statement.  However, autoreconf complained that hte macro
was expanded more than once.  Is the way I'm doing this kosher?  Is it
"The Right Way", or is there a better approach?  (for the whole thing,
not just the AM_COND_IF part)

RE: split check target into check and test targets

[Daily, Jeff A]

> > I attempted to split the "make check" target into "make check"
> > (build check_PROGRAMS) and "make test" (run check_PROGRAMS).
> > However, I get warnings that check-am was overridden.  How might I
> > split the building and running of check_PROGRAMS and still use the
> > generated parallel-tests using TESTS?  Thanks.
> 
> You are trying to do something which violates the GNU coding
> standards since 'check' has a standard definition.
> 
> If you use a different target name then there should be no problem:
> 
> checkprogs : check_PROGRAMS
> 
> test : check
> 

Ok, fair enough.  But what's the easiest way to create a new recursive target 
such as checkprogs?  Hopefully there's a more or less automatic way using 
automake.  I have quite a few subdirectories each with a few test program 
directories so it would be tedious to make this change.  Is there some way to 
tap into the RECURSIVE_TARGETS variable?

Thanks,

Jeff

Re: split check target into check and test targets

[John Calcote]

On 2/24/2010 1:50 AM, Baurzhan Ismagulov wrote:

On Tue, Feb 23, 2010 at 04:05:47PM -0800, Daily, Jeff A wrote:
   

I attempted to split the "make check" target into "make check" (build
check_PROGRAMS) and "make test" (run check_PROGRAMS). However, I get
warnings that check-am was overridden. How might I split the building
and running of check_PROGRAMS and still use the generated
parallel-tests using TESTS? Thanks.
 

There are also these ways:
http://www.opensubscriber.com/message/automake@gnu.org/2136673.html
   


Additionally, if I want to build a particular check program (perhaps as 
I'm working out the compiler errors, but before I'm ready to actually 
run the tests), I just type "make " from that 
directory. Alexander's solution is great, though. I'm going to use that 
one myself.


Regards,
John

Re: split check target into check and test targets

[Ralf Wildenhues]

* Daily, Jeff A wrote on Wed, Feb 24, 2010 at 07:09:36PM CET:
> > If you use a different target name then there should be no problem:
> > 
> > checkprogs : check_PROGRAMS
> > 
> > test : check

> Ok, fair enough.  But what's the easiest way to create a new recursive
> target such as checkprogs?  Hopefully there's a more or less automatic
> way using automake.

No, it's not, which is a real bummer.  Best you can do is somehow copy
the $(RECURSIVE_TARGETS) rule as a fragment file and include that in the
other Makefile.am files.

I'd like to improve this situation at some point.

Cheers,
Ralf

Re: Automake conditionals in autoconf

[Ralf Wildenhues]

Hello,

* NightStrike wrote on Wed, Feb 24, 2010 at 06:29:04PM CET:
> AC_MSG_CHECKING([whether to build the optional libraries])
> AC_ARG_WITH([libraries],
>   [AS_HELP_STRING([--with-libraries=ARG],
> [Build the extra mingw-w64 libs, where ARG is one of libmangle,
> pseh, or all])],
>   [],
>   [with_libraries=no])
> AS_CASE([$with_libraries],
>   [yes|all],[
> with_libraries="libmangle,pseh"
> with_libraries_mangle=yes
> with_libraries_pseh=yes],
>   [libmangle],[
> with_libraries="libmangle"
> with_libraries_mangle=yes
> with_libraries_pseh=no],
>   [pseh],[
> with_libraries="pseh"
> with_libraries_mangle=no
> with_libraries_pseh=yes],
>   [no],[
> with_libraries_mangle=no
> with_libraries_pseh=no],
>   [AC_MSG_ERROR([Invalid argument to --with-libraries: $with_libraries])])
> AM_CONDITIONAL([LIBRARIES_MANGLE],[test "x$with_libraries_mangle" = xyes])
> AM_CONDITIONAL([LIBRARIES_PSEH],[test "x$with_libraries_pseh" = xyes])
> AM_COND_IF([LIBRARIES_MANGLE],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/libmangle])])
> AM_COND_IF([LIBRARIES_PSEH],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/pseh])])
> AC_MSG_RESULT([$with_libraries])
> 
> 
> Those two AM_COND_IF lines at the bottom didn't use to be there.
> Instead, I had the AC_CONFIG_SUBDIRS lines in each appropriate branch
> of the case statement.  However, autoreconf complained that hte macro
> was expanded more than once.  Is the way I'm doing this kosher?  Is it
> "The Right Way", or is there a better approach?  (for the whole thing,
> not just the AM_COND_IF part)

The above looks ok to me.  Since I cannot, from your description,
exactly reproduce the code that caused the warning for you, I cannot say
whether that was a problem.

The code as above does not yet take care of adjusting SUBDIRS (and maybe
DIST_SUBDIRS) in the toplevel Makefile.  There is one decision for you
to make here: should 'make dist' tar up all subpackages, even those that
aren't build (which is the default, because that's what's right to
ensure downstream has the same choices as you) in which case you can
just

  if LIBRARIES_MANGLE
  SUBDIRS += mingw-w64-libraries/libmangle
  endif
  ...

In the other case you should use something like
  AC_SUBST([libmangle_subdir], [mingw-w64-libraries/libmangle])
and

  SUBDIRS = ... $(libmangle_subdir) ...

Hope that helps.

Cheers,
Ralf

Re: Automake conditionals in autoconf

[NightStrike]

On Wed, Feb 24, 2010 at 2:23 PM, Ralf Wildenhues  wrote:
> The above looks ok to me.  Since I cannot, from your description,
> exactly reproduce the code that caused the warning for you, I cannot say
> whether that was a problem.
>
> The code as above does not yet take care of adjusting SUBDIRS (and maybe
> DIST_SUBDIRS) in the toplevel Makefile.  There is one decision for you
> to make here: should 'make dist' tar up all subpackages, even those that
> aren't build (which is the default, because that's what's right to
> ensure downstream has the same choices as you) in which case you can
> just
>
>  if LIBRARIES_MANGLE
>  SUBDIRS += mingw-w64-libraries/libmangle
>  endif
>  ...

I used the DIST OPTIONS thing to enable all sub packages for
distribution.  See my links below for how I did it (hopefully I chose
a method that's ok)

> In the other case you should use something like
>  AC_SUBST([libmangle_subdir], [mingw-w64-libraries/libmangle])
> and
>
>  SUBDIRS = ... $(libmangle_subdir) ...

Well, I committed it to svn, so everything is available here:
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/Makefile.am?view=markup
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/configure.ac?view=markup

Previously, in the case statements, I had AC_CONFIG_SUBDIRS in each
path.  For instance:

[yes|all],[
   with_libraries="libmangle,pseh"
   with_libraries_mangle=yes
   with_libraries_pseh=yes
   AC_CONFIG_SUBDIRS([mingw-w64-headers/libraries/libmangle])
   AC_CONFIG_SUBDIRS([mingw-w64-headers/libraries/pseh])],
[libmangle],[
   with_libraries="libmangle"
   with_libraries_mangle=yes
   with_libraries_pseh=no
   AC_CONFIG_SUBDIRS([mingw-w64-headers/libraries/libmangle])],
...etc

That tossed an error saying that the directory libmangle was already
in the list of stuff to be configured.

RE: split check target into check and test targets

[Daily, Jeff A]

> > Ok, fair enough.  But what's the easiest way to create a new
> recursive
> > target such as checkprogs?  Hopefully there's a more or less
> automatic
> > way using automake.
> 
> No, it's not, which is a real bummer.  Best you can do is somehow copy
> the $(RECURSIVE_TARGETS) rule as a fragment file and include that in
> the
> other Makefile.am files.
> 
> I'd like to improve this situation at some point.
> 
> Cheers,
> Ralf

Good advice, Ralf.  I've done just that.  Now I have the freedom to add any 
recursive targets I need.

I used find with sed to insert into the top of all of my Makefile.am files:

find -name 'Makefile.am' -exec sed -i '1i\include 
$(top_srcdir)/config/ga_recur.mk\n' {} \;

All I need to do is add a few lines to my ga_recur.mk to add additional 
recursive targets, if I ever need them.  I could probably have removed the -am 
target stuff, right?  Oh, well.  There were only a handful of Makefile.am files 
which had a check_PROGRAMS target, so in those files I've added:

TESTS = $(check_PROGRAMS)
checkprogs:
$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)

The contents of ga_recur.mk are:

# COPIED FROM MAKEFILE GENERATED BY AUTOMAKE 1.11.1
# 
# Modified to use our own recursive targets.
#
# This directory's subdirectories are mostly independent; you can cd
# into them and run `make' without going through this Makefile.
# To change the values of `make' variables: instead of editing Makefiles,
# (1) if the variable is set in `config.status', edit `config.status'
# (which will cause the Makefiles to be regenerated when you run `make');
# (2) otherwise, pass the desired values on the `make' command line.
$(GA_RECURSIVE_TARGETS):
@fail= failcom='exit 1'; \
for f in x $$MAKEFLAGS; do \
  case $$f in \
*=* | --[!k]*);; \
*k*) failcom='fail=yes';; \
  esac; \
done; \
dot_seen=no; \
target=`echo $@ | sed s/-recursive//`; \
list='$(SUBDIRS)'; for subdir in $$list; do \
  echo "Making $$target in $$subdir"; \
  if test "$$subdir" = "."; then \
dot_seen=yes; \
local_target="$$target-am"; \
  else \
local_target="$$target"; \
  fi; \
  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
  || eval $$failcom; \
done; \
if test "$$dot_seen" = "no"; then \
  $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
fi; test -z "$$fail"
# END COPY

GA_RECURSIVE_TARGETS = checkprogs-recursive

checkprogs: checkprogs-recursive
checkprogs-am:

Re: split check target into check and test targets

[Ralf Wildenhues]

* John Calcote wrote on Wed, Feb 24, 2010 at 07:17:08PM CET:
> On 2/24/2010 1:50 AM, Baurzhan Ismagulov wrote:
> >On Tue, Feb 23, 2010 at 04:05:47PM -0800, Daily, Jeff A wrote:
> >>I attempted to split the "make check" target into "make check" (build
[...]
> >http://www.opensubscriber.com/message/automake@gnu.org/2136673.html
> 
> Additionally, if I want to build a particular check program (perhaps
> as I'm working out the compiler errors, but before I'm ready to
> actually run the tests), I just type "make "
> from that directory. Alexander's solution is great, though. I'm
> going to use that one myself.

Actually.  I think I should write some more on this, and recommend y'all
rethink.  :-)

Dunno if you've heard of the parallel-tests option (enabling a newer
testsuite driver), but if you haven't, then read


It allows to run tests in parallel (hence the name), but it also allows
interleaving of test program building and test running (a feature that
was IIRC the main motivation for Akim to develop this driver).  It also
allows you to sort of rerun only tests that are out of date (once you
have formulated dependencies for not only test programs, but also test
results).  The way to get interleaved test program building and
execution is to use EXTRA_PROGRAMS instead of check_PROGRAMS (see the
manual), which is nice if you have only a couple of those that need
updating, and building is not a lot faster/slower than test execution.

One other note I think is in place is that one can change check_PROGRAMS
to noinst_PROGRAMS to have them built with 'make all' already (gnulib
encourages this, for example, in order to see build failures at 'all'
time already.  This sort of goes in the other direction, away from
"rebuild as lazily as possible, for more parallelism" but can be very
useful as well (and with lots of test programs, allows a lot of
parallelism too).

Hope that helps.  If you have any questions feel free to ask.

Cheers,
Ralf

Re: Problem of: variable `main_SOURCES' is defined but no program or library has `main' as canonical name (possible typo)

[Ralf Wildenhues]

Hello Bill,

* Mi Yang (杨觅) wrote on Wed, Feb 24, 2010 at 03:34:26PM CET:
> I met a strange problem when "automake -a":
> 
> core/Makefile.am:3: variable `main_SOURCES' is defined but no program or
> core/Makefile.am:3: library has `main' as canonical name (possible typo)

Well, it is meant as a help for typos.  You define the variable
main_SOURCES, which usually means that the program named 'main' is to
be compiled from the source files listed in that variable.  For the
program to be registered as such, add it to bin_PROGRAMS, or
noinst_PROGRAMS or similar, e.g.,
  bin_PROGRAMS = main

If that doesn't help you, then it would be good if you showed us your
core/Makefile.am so we could help better.

Cheers,
Ralf

Re: split check target into check and test targets

[Daily, Jeff A]

>  Just add your own rule that depends on $(check_PROGRAMS):
>
> .PHONY: check-norun
> check-norun: $(check_PROGRAMS)
>
> and type `make check-norun' instead of `make check'.

I copied the above from the link since I had trouble navigating to it.

This is a great solution for building the check_PROGRAMS from within the same 
directory.  But what I needed was a new recursive target to build the 
check_PROGRAMS throughout my build tree.  I've posted my solution elsewhere in 
this thread, but I just realized I missed the use .PHONY there.  Thanks.

Jeff

Re: Proper way to link Fortran with C++

[Ralf Wildenhues]

Hello Steven,

sorry to bother you.  Jö asked this on the Automake mailing list:

* Jö Fahlke wrote on Tue, Feb 23, 2010 at 10:06:01AM CET:
> Our project uses C++, but some of its optional dependencies require linking
> with fortran libraries (like blas).  What is the proper way to do this?
> 
> On the one hand the Autoconf documentation says that the output variable FLIBS
> should be included after LIBS when linking.  This is consistent with the
> documentation for ACX_BLAS from the Autoconf archive, which states
> 
> #   To link with BLAS, you should link with:
> #
> #   $BLAS_LIBS $LIBS $FLIBS
> #
> #   in that order.
> 
> The Automake documentation on the other hand states that I should put $(FLIBS)
> into the apropriate _LDADD or _LIBADD variable.  That would include the value
> of FLIBS before the value of LIBS on the linker command line, contradicting
> the autoconf documentation.
> 
> Is there a reason Autconf requires FLIBS after LIBS, and not just FLIBS after
> the library actually using fortran?  That would be
> 
>$BLAS_LIBS $FLIBS $LIBS
> 
> in the case of blas, and it would allow me to fold FLIBS into BLAS_LIBS.  This
> in turn would make it easier to omit the FLIBS completely in case blas was not
> detected by configure.

Do you remember why the Autoconf macro specifically recommends
this ordering?  We should amend it with a rationale.

I couldn't find anything in the archives of the macro sources about it.
Maybe it is because $LIBS may contain a Fortran library?

Thanks,
Ralf

Re: split check target into check and test targets

[Baurzhan Ismagulov]

On Wed, Feb 24, 2010 at 08:49:26PM +0100, Ralf Wildenhues wrote:
> Dunno if you've heard of the parallel-tests option
...
> It also allows you to sort of rerun only tests that are out of date

Wow! Does it work with DejaGNU? Which automake version is required?


> (once you have formulated dependencies for not only test programs, but
> also test results)

Can't automake do the former automatically? Could you give an example
use case for the latter?


With kind regards,
-- 
Baurzhan Ismagulov
http://www.kz-easy.com/

Re: Proper way to link Fortran with C++

[Steven G. Johnson]

Ralf Wildenhues wrote:

The Automake documentation on the other hand states that I should put $(FLIBS)
into the apropriate _LDADD or _LIBADD variable.  That would include the value
of FLIBS before the value of LIBS on the linker command line, contradicting
the autoconf documentation.

Is there a reason Autconf requires FLIBS after LIBS, and not just FLIBS after
the library actually using fortran?  That would be

   $BLAS_LIBS $FLIBS $LIBS

in the case of blas, and it would allow me to fold FLIBS into BLAS_LIBS.  This
in turn would make it easier to omit the FLIBS completely in case blas was not
detected by configure.


Do you remember why the Autoconf macro specifically recommends
this ordering?  We should amend it with a rationale.

I couldn't find anything in the archives of the macro sources about it.
Maybe it is because $LIBS may contain a Fortran library?


Yes.

The only reason to check for FLIBS is to link to Fortran libraries from 
a non-Fortran program.  And the standard way to check for libraries is 
to use AC_CHECK_LIB, which by default adds the library to LIBS, rather 
than using a separate variable ala BLAS_LIBS (and often people who use 
e.g. ACX_BLAS just add $BLAS_LIBS to LIBS).


Also, putting libraries into LIBS is important for several other 
autoconf macros to work normally, e.g. AC_CHECK_FUNC.


So, the point is to allow people to use AC_CHECK_LIB normally after 
calling AC_F77_LIBRARY_LDFLAGS (and possibly AC_F77_FUNC to find the 
appropriate C linker name for a Fortran identifier).


Regards,
Steven G. Johnson

Re: Proper way to link Fortran with C++

[Steven G. Johnson]

Ralf Wildenhues wrote:

The Automake documentation on the other hand states that I should put $(FLIBS)
into the apropriate _LDADD or _LIBADD variable.  That would include the value
of FLIBS before the value of LIBS on the linker command line, contradicting
the autoconf documentation.

Is there a reason Autconf requires FLIBS after LIBS, and not just FLIBS after
the library actually using fortran?  That would be

   $BLAS_LIBS $FLIBS $LIBS

in the case of blas, and it would allow me to fold FLIBS into BLAS_LIBS.  This
in turn would make it easier to omit the FLIBS completely in case blas was not
detected by configure.


Do you remember why the Autoconf macro specifically recommends
this ordering?  We should amend it with a rationale.

I couldn't find anything in the archives of the macro sources about it.
Maybe it is because $LIBS may contain a Fortran library?


Yes.

The only reason to check for FLIBS is to link to Fortran libraries from 
a non-Fortran program.  And the standard way to check for libraries is 
to use AC_CHECK_LIB, which by default adds the library to LIBS, rather 
than using a separate variable ala BLAS_LIBS (and often people who use 
e.g. ACX_BLAS just add $BLAS_LIBS to LIBS).


Also, putting libraries into LIBS is important for several other 
autoconf macros to work normally, e.g. AC_CHECK_FUNC.


So, the point is to allow people to use AC_CHECK_LIB normally after 
calling AC_F77_LIBRARY_LDFLAGS (and possibly AC_F77_FUNC to find the 
appropriate C linker name for a Fortran identifier).


Regards,
Steven G. Johnson

cannot specify -o with -c or -S

[rrlangly]

Does anyone have an idea as to why I'd get the following error when compiling
my program using autotools. This used to compile and run, then I added new
code and linked against a new library, and now I get this.

g++ -DHAVE_CONFIG_H -I. -I../../GXT/src -I..  -I../../GXT/include
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I
/usr/include/festival -I /usr/include/speech-tools -I/usr/include/boost -I
/usr/local/include -I /usr/local/include/OGRE/Terrain
-I/usr/local/include/OGRE/Paging -I/usr/local/include/OGRE -I
/opt/ion-inb-1.1.0/include -I/home/priggy/Projects/subA/libbern
/home/priggy/Projects/subA/asn.1/bern-sn.h
/home/priggy/Projects/subA/util/bern-ut.h
/home/priggy/Projects/subA/util/bern-no.h
/home/priggy/Projects/subA/util/bern-res.h
/home/priggy/Projects/subA/util/bern-am.h
/home/priggy/Projects/subA/util/bern-da.h
/home/priggy/Projects/subA/util/bern-v.h
/home/priggy/Projects/subA/util/bern-ver.h
/home/priggy/Projects/subA/libbbc/bbc-c.h  -pthread -I/usr/local/include
-I/usr/local/include/OGRE   -I/usr/include/OIS   -g -O2 -MT gtx-main.o -MD
-MP -MF .deps/gtx-main.Tpo -c -o gtx-main.o `test -f 'main.cpp' || echo
'../../GXT/src/'`main.cpp
g++: cannot specify -o with -c or -S with multiple files
make[3]: *** [gtx-main.o] Error 1


This isn't the exact Makefile (which I don't have access to now), but it
contains the very same macros, or not sure what they're called (e.g.
_SOURCES, _CPPFLAGS, _LDADD, etc...).

--- Makefile.am ---
bin_PROGRAMS = myprog

myprog_SOURCES =\
main.cpp   \
classb.cpp   \
classc.cpp   \
classd.cpp

myprog_CXXFLAGS= $(OGRE_CFLAGS) $(OIS_CFLAGS)

myprog_CPPFLAGS = -I$(top_srcdir)/include 

myprog_LDFLAGS = -L/usr/lib64 -L/usr/local/lib64 -L/usr/local/lib 

myprog_LDADD = $(OGRE_LIBS) $(OIS_LIBS) -lopenal 

SUBDIRS= libs



Any helpl much appreciated.
-- 
View this message in context: 
http://old.nabble.com/cannot-specify--o-with--c-or--S-tp27714351p27714351.html
Sent from the Gnu - Automake - General mailing list archive at Nabble.com.

Re: cannot specify -o with -c or -S

[Russ Allbery]

rrlangly  writes:

> Does anyone have an idea as to why I'd get the following error when
> compiling my program using autotools. This used to compile and run, then
> I added new code and linked against a new library, and now I get this.

> g++ -DHAVE_CONFIG_H -I. -I../../GXT/src -I..  -I../../GXT/include
> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I
> /usr/include/festival -I /usr/include/speech-tools -I/usr/include/boost -I
> /usr/local/include -I /usr/local/include/OGRE/Terrain
> -I/usr/local/include/OGRE/Paging -I/usr/local/include/OGRE -I
> /opt/ion-inb-1.1.0/include -I/home/priggy/Projects/subA/libbern
> /home/priggy/Projects/subA/asn.1/bern-sn.h
> /home/priggy/Projects/subA/util/bern-ut.h
> /home/priggy/Projects/subA/util/bern-no.h
> /home/priggy/Projects/subA/util/bern-res.h
> /home/priggy/Projects/subA/util/bern-am.h
> /home/priggy/Projects/subA/util/bern-da.h
> /home/priggy/Projects/subA/util/bern-v.h
> /home/priggy/Projects/subA/util/bern-ver.h
> /home/priggy/Projects/subA/libbbc/bbc-c.h

This is the broken part.  Somehow, that list of individual header files
got plugged into what looks like the CPPFLAGS setting for this
compilation, so they look like individual source files.  I suspect that
somewhere you're setting the wrong Automake variable to a list of header
files, although I don't see that in the Makefile.am excerpt that you
included.

-- 
Russ Allbery (r...@stanford.edu) 

Re: cannot specify -o with -c or -S

[Ralf Corsepius]

On 02/25/2010 06:16 AM, rrlangly wrote:


Does anyone have an idea as to why I'd get the following error when compiling
my program using autotools. This used to compile and run, then I added new
code and linked against a new library, and now I get this.

g++ -DHAVE_CONFIG_H -I. -I../../GXT/src -I..  -I../../GXT/include
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I
/usr/include/festival -I /usr/include/speech-tools -I/usr/include/boost -I
/usr/local/include -I /usr/local/include/OGRE/Terrain
-I/usr/local/include/OGRE/Paging -I/usr/local/include/OGRE -I
/opt/ion-inb-1.1.0/include -I/home/priggy/Projects/subA/libbern
/home/priggy/Projects/subA/asn.1/bern-sn.h
/home/priggy/Projects/subA/util/bern-ut.h
/home/priggy/Projects/subA/util/bern-no.h
/home/priggy/Projects/subA/util/bern-res.h
/home/priggy/Projects/subA/util/bern-am.h
/home/priggy/Projects/subA/util/bern-da.h
/home/priggy/Projects/subA/util/bern-v.h
/home/priggy/Projects/subA/util/bern-ver.h
/home/priggy/Projects/subA/libbbc/bbc-c.h

The cause for the compiler to abort is this list of headers above.


-pthread -I/usr/local/include
-I/usr/local/include/OGRE   -I/usr/include/OIS   -g -O2 -MT gtx-main.o -MD
-MP -MF .deps/gtx-main.Tpo -c -o gtx-main.o `test -f 'main.cpp' || echo
'../../GXT/src/'`main.cpp
g++: cannot specify -o with -c or -S with multiple files
make[3]: *** [gtx-main.o] Error 1


This isn't the exact Makefile (which I don't have access to now), but it
contains the very same macros, or not sure what they're called (e.g.
_SOURCES, _CPPFLAGS, _LDADD, etc...).

--- Makefile.am ---
bin_PROGRAMS = myprog

myprog_SOURCES =\
 main.cpp   \
 classb.cpp   \
 classc.cpp   \
 classd.cpp

myprog_CXXFLAGS= $(OGRE_CFLAGS) $(OIS_CFLAGS)

myprog_CPPFLAGS = -I$(top_srcdir)/include

myprog_LDFLAGS = -L/usr/lib64 -L/usr/local/lib64 -L/usr/local/lib

myprog_LDADD = $(OGRE_LIBS) $(OIS_LIBS) -lopenal

SUBDIRS= libs



Any helpl much appreciated.

Well, this Makefile.am doesn't correspond to the breakdown above.

You will want to check for where this series of *.h's originates from.

Ralf

Re: cannot specify -o with -c or -S

[Harlan Stenn]

Richard,

Why are all the header files from Projects/subA/ being enumerated in the
compile line?  I think that's the problem.

H