On Sunday 2023-03-26 14:33, Labeeb Asari wrote:
>
>Basically : compile .c source files with gcc, .cu files with nvcc and
>finally link them together with gcc.
>
>I've tried adding a rule to handle .cu files differently and it does create
>object files for it separately
g to do :
https://github.com/labeeb-7z/cuda-gnu/tree/main/shared-library
Basically : compile .c source files with gcc, .cu files with nvcc and
finally link them together with gcc.
I've tried adding a rule to handle .cu files differently and it does create
object files for it separately. However wh
lt;http://www.perl.org/>
FSUM8226 make: Error code 127
make: './aclocal.m4' removed.
As you can see, it seems to want automake 1.15 or higher, and I only have 1.10.
Why is make this way round still requiring aclocal 1.15?
Thanks again,
Andy
____
From: Eri
x27;make dist' argument before, but it would prerequisite that
I chose the appropriate configure and make arguments to compile for the
platform I am targeting.thoughts?
'make dist' is SUPPOSED to produce an idempotent and complete tarball
(modulo noise like changes in time
chose the appropriate configure and
make arguments to compile for the platform I am targeting.thoughts? I am
not even sure of the official 'name' of the system I am targeting? s390? omvs?
To be clear, I am targeting USS on zSystems, not Linux on z. Thoughts? Bes
On 05/30/2018 11:12 AM, Andy Armstrong wrote:
To give some context to what I am doing, here is the timeline:
I did have Automake version 1.10, but my ultimate goal here is to compile the
nano text editor, which requires at least automake 1.15 and autoconf 2.69.
That's if you are modi
Makefile
.SOURCE : .NULL
@B = $(@:b)
@D = $(@:d)
@F = $(@:f)
%B = $(%:b)
%D = $(%:d)
%F = $(%:f)
*B = $(*:b)
*D = $(*:d)
*F = $(*:f)
Sent: 30 May 2018 15:13
To: Andy Armstrong; automake@gnu.org
Subject: Re: automake compile problems
On 05/30/2018 04:07 AM, Andy Armstrong wrote:
> Hi all,
>
>
&g
On Wed, 30 May 2018, Eric Blake wrote:
On 05/30/2018 04:07 AM, Andy Armstrong wrote:
Hi all,
I want to compile version 1.16 of automake.
On which system?
Must be IBM, and perhaps z/OS:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxa800/fsum9432.htm
Bob
On 05/30/2018 04:07 AM, Andy Armstrong wrote:
Hi all,
I want to compile version 1.16 of automake.
On which system?
I run ./configure, which creates the Makefile. I run 'make' which results in
the following:
automake-1.16: >make
make: Makefile: line 3012: Warning -- FSUM9
Hi all,
I want to compile version 1.16 of automake.
I run ./configure, which creates the Makefile. I run 'make' which results in
the following:
automake-1.16: >make
make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry
[t/get-sysconf.sh] in target list
make: Makefi
Terminal output goes here:
$ make GEN bin/automake GEN bin/aclocal GEN
bin/aclocal-1.16 GEN bin/automake-1.16 GEN
t/ax/shell-no-trail-bslash GEN t/ax/cc-no-c-o GEN runtest GEN
doc/aclocal.1 GEN doc/automake.1 GEN lib/Automak
On 01/25/18 04:07, Jay K wrote:
I have a bunch of C.
I want to move to C++.
I'm using automake.
I don't want to rename any files.
that's unwise and not going to serve you well in the long run. I very much
advise against not renaming files converted from C to C++. While it can be done,
this is
I have a bunch of C.
I want to move to C++.
I'm using automake.
I don't want to rename any files.
Fortunately I already build libraries and then main separately. That might
help, or not matter.
So I want to say:
libfoo_la_CFLAGS += -xc++
and possibly
main_CFLAGS += -xc
Or something higher level
ke distcheck
> [...]
>dist-hook
> make[3]: Entering directory
> '/home/roelof/devel/limereg/limereg-1.3.1/_build'
> for file in ../config/compile ../config/config.guess
> ../config/config.sub ../config/depcomp ../config/install-sh
> ../config/ltmain.sh ../conf
very well and its output can be built on a clean
system, all tests pass, the tarball seems to be perfectly ok. 'make
distcheck', however, complains about missing files:
prompt$ make distcheck
[...]
dist-hook
make[3]: Entering directory
'/home/roelof/devel/limereg/limereg-1.3
some things like automake/autoconf/libtool... and they rely on
perl as well as each of them needing themselves for autogen. Thus I
cross-compile automake, help2man, autoconf, libtool, intltool on amd64 and
since perl doesn't need any bootstrap, I can build perl from arm.So on the arm
device
On Wed, Dec 18, 2013 at 10:55 PM, Jordan H. wrote:
> myprog_LDFLAGS = `pkg-config --libs sqlite3 gmodule-2.0`
> myprog_LDFLAGS += -Wl,-export-dynamic
>
Don't use _LDFLAGS for libraries, it's broken and may not work depending on
your distribution's configuration of the toolchain.
Diego E
Hi,
On Dec 18, 2013, at 19:34 , Jordan H. wrote:
Relevant part of configure.ac:
PKG_CHECK_MODULES(SQLITE, [sqlite3 > $SQLITE_REQUIRED_VERSION])
You probably want to turn SQLITE into SQLITE3 there? Also I don't
think $SQLITE_REQUIRED_VERSION as a shell variable will work the way
you thi
Hello,
On Dec 18, 2013, at 22:26 , Jordan H. wrote:
Thanks but I'm still getting the same error.
can you provide the result of the following commands to get a better
idea of what's going wrong:
$ grep SQLITE_ config.log
$ grep program_CFLAGS Makefile
after running configure?
configure.a
$(GMODULE_LIBS)
myprog_LDFLAGS += -Wl,-export-dynamic
...I get compile errors for sqlite. If I add in the lines...
myprog_CFLAGS += `pkg-config --cflags sqlite3`
myprog_LDFLAGS = `pkg-config --libs sqlite3`
...but leave out `pkg-config ... glib-2.0` I get errors like the following:
On Wed, Dec 18, 2013 at 9:26 PM, Jordan H. wrote:
> Makefile.am:
>
> program_CFLAGS += @SQLITE_CFLAGS@
> program_LDADD += @SQLITE_LIBS@
>
First you should not need to use AC_SUBST() for these variables at all if
you have the right pkg.m4.
Second, can you please post the full Makefile.am
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Thanks but I'm still getting the same error.
configure.ac:
...
m4_define(SQLITE_REQUIRED_VERSION, 3.0)
...
PKG_CHECK_MODULES(SQLITE, [sqlite >= $SQLITE_REQUIRED_VERSION])
AC_SUBST([SQLITE_CFLAGS])
AC_SUBST([SQLITE_LIBS])
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Relevant part of configure.ac:
PKG_CHECK_MODULES(SQLITE, [sqlite3 > $SQLITE_REQUIRED_VERSION])
AC_SUBST([SQLITE3_CFLAGS])
AC_SUBST([SQLITE3_LIBS])
Even without $SQLITE_REQUIRED_VERSION it still fails.
Relevant part of makefile.am:
On 08/22/2012 03:52 PM, Stefano Lattarini wrote:
> OTOH, I believe developers working on older systems should be ready to
> install more recent developer tools once in a while. You can't truly
> expect not to update your Automake installation for 3, 4 years!
Oh, _I_ fully wish that RHEL 5 would
Il 22/08/2012 23:52, Stefano Lattarini ha scritto:
>> > I'd much rather a mandatory noisy warning period before a feature is
>> > completely removed.
>> >
> This would require a new category of warnings that are are unconditionally
> show, regardless of strictness or any "-Wnone" option. As usual,
gmail.com>
>> From: Stefano Lattarini
>> Date: Wed, 22 Aug 2012 16:40:15 +0200
>> Subject: [PATCH] compile: remove support for $(INCLUDES)
>>
>> It has already been deprecated in the manual and by warnings in the
>> 'obsolete' categories for ages (at least si
Aug 2012 16:40:15 +0200
> Subject: [PATCH] compile: remove support for $(INCLUDES)
>
> It has already been deprecated in the manual and by warnings in the
> 'obsolete' categories for ages (at least since 2003), in favour of
> AM_CPPFLAGS. Automake-NG has removed support for it
On Wed, Aug 22, 2012 at 10:12 PM, Paolo Bonzini wrote:
> On Wed, Aug 22, 2012 at 5:12 PM, Stefano Lattarini
> wrote:
>> On 08/21/2012 06:03 PM, Paolo Bonzini wrote:
>>>
Looking at GNU Smalltalk, I see:
* warn for INCLUDES (vs. AM_CPPFLAGS)
>> Turns out this has already been do
On 22/08/2012 12:12, Paolo Bonzini wrote:
> What about first making the warning visible always, not just with
> -Wobsolete? And add to the message that support will be removed in
> 1.14.
+1
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
On Wed, Aug 22, 2012 at 5:12 PM, Stefano Lattarini
wrote:
> On 08/21/2012 06:03 PM, Paolo Bonzini wrote:
>>
>>> Looking at GNU Smalltalk, I see:
>>>
>>> * warn for INCLUDES (vs. AM_CPPFLAGS)
>>>
> Turns out this has already been done for ages (at least since 2003).
> I'll just remove support for i
...@gmail.com>
From: Stefano Lattarini
Date: Wed, 22 Aug 2012 16:40:15 +0200
Subject: [PATCH] compile: remove support for $(INCLUDES)
It has already been deprecated in the manual and by warnings in the
'obsolete' categories for ages (at least since 2003), in favour of
AM_CPPFLAGS.
Perfect. Thanks for the help and fast response! I have two good solutions to
work from.
Kindly,
Graham
On May 23, 2011, at 8:48 PM, Daniel Herring wrote:
> On Mon, 23 May 2011, Daniel Herring wrote:
>
>> FYI, when I install a new version of the autotools, I do something like
>>
>> # PATH=/
On Mon, 23 May 2011, Daniel Herring wrote:
FYI, when I install a new version of the autotools, I do something like
# PATH=/new/path/bin:$PATH
# cd m4; ./configure --prefix=/new/path; make; make install
# cd ../autoconf; ./configure --prefix=/new/path; make; make install
# cd ../automake; ./conf
FYI, when I install a new version of the autotools, I do something like
# PATH=/new/path/bin:$PATH
# cd m4; ./configure --prefix=/new/path; make; make install
# cd ../autoconf; ./configure --prefix=/new/path; make; make install
# cd ../automake; ./configure --prefix=/new/path; make; make install
Awesome. Thanks Stefano.
>> Host platform: OS X 10.6.7
>>
> Just out of curiousity: how old is this release, and which autoconf version
> are they shipping with it?
10.6.7 is the latest version of OS X.
It ships with (Copyright signature removed from the output):
grahamreitz$ automake --ve
On Monday 23 May 2011, Graham Reitz wrote:
> Is their a configure switch to indicate that an alternative autoconf
> should be used, rather than defaulting to the autoconf located in
> /usr/local/bin?
>
Yes: override the AUTOCONF and AUTOM4TE variables (yes, you need
to override both); e.g.:
./con
Is their a configure switch to indicate that an alternative autoconf should be
used, rather than defaulting to the autoconf located in /usr/local/bin?
With other gnu build deps there is often a --with-*dep=$path_to_dep. Is there
an equivalent when building automake from source?
Host platform:
Stefano Lattarini wrote:
> Which compiler(s) are you using exactly?
i686-w64-mingw32, compiled from source. The compiler is the same one
that was working correctly just recently.
> Which version(s)?
gcc version 4.5.0 20100329 (experimental) (GCC)
> More importantly, which version of libtool
On Sunday 08 May 2011, Erik de wrote:
> Hi all,
>
Hi Eric, sorry for the delay.
> I all I have a rather large Makefile.am that used to work for both
> native compiles on linux and cross compiles from linux to windows.
> This suddenly stopped working with automake 1.11.1 from debian.
>
Which compil
Erik de Castro Lopo wrote:
> The problem is that the test programs don't get built. Or rather
> something gets built and put in the G72x/.libs directory, but there
> is nothing in the G72x/ directory for the generated Makefile to run.
Just as an addendum to this bug report, the G72x/.libs/ direct
Hi all,
I all I have a rather large Makefile.am that used to work for both
native compiles on linux and cross compiles from linux to windows.
This suddenly stopped working with automake 1.11.1 from debian.
The relevant parts of the Makefile.am are:
AUTOMAKE_OPTIONS = subdir-objects
noin
led report.
> I'm Cc'ing the automake list, since that's
> the source of the compile script.
Thanks, and sorry for not digging further to notice this!
[snip]
> > The src/Makefile does not list copy.o as a dependency of mv.pm
> > (Oops), so Make does not rebuild
Green, Paul wrote:
> Gentle Coreutils Developers,
>
> I am writing to notify you of an issue that I stumbled across while
> building coreutils-8.12 on the Stratus OpenVOS platform.
Hi Paul,
Thanks for the detailed report.
I'm Cc'ing the automake list, since that'
Stefano Lattarini wrote:
> On Thursday 05 May 2011, Jim Meyering wrote:
>> Green, Paul wrote:
>> > Gentle Coreutils Developers,
>> >
> [HUGE CUT]
>>
>> To the automake folks, is there any reason not to do that?
>>
>
> Hi Jim. I'm in a middle of something else right now, so I'm
> probably not going
Is there any reason not to make the compile script
accommodate (in a race-free manner) situations like
the one described in http://debbugs.gnu.org/8616 ?
On Thursday 05 May 2011, Jim Meyering wrote:
> Green, Paul wrote:
> > Gentle Coreutils Developers,
> >
[HUGE CUT]
>
> To the automake folks, is there any reason not to do that?
>
Hi Jim. I'm in a middle of something else right now, so I'm
probably not going to look into this soonish. Could you
On Tue, 5 Apr 2011, Dave Hart wrote:
On Mon, Apr 4, 2011 at 22:15 PM, Martin Hicks wrote:
Is there a way to specify a different compiler for compile-time helper
programs that are used during the build of a package?
I think the short answer is no. I have some source files in a package
which
On Mon, Apr 4, 2011 at 22:15 PM, Martin Hicks wrote:
> Is there a way to specify a different compiler for compile-time helper
> programs that are used during the build of a package?
I think the short answer is no. I have some source files in a package
which are built by running a C p
I've run into this a few times and I've never seen a solution.
Is there a way to specify a different compiler for compile-time helper
programs that are used during the build of a package? Basically the
HOSTCC vs. Target CC that is implemented in the linux kernel tree for
cross compil
ping 3 :)
On Mon, Jan 24, 2011 at 10:09 AM, Vincent Torri wrote:
>
> ping2 :)
>
> Vincent Torri
>
> On Tue, Jan 4, 2011 at 8:24 AM, Vincent Torri wrote:
>
>>
>> Hey,
>>
>> Wasn't what i want (see below) clear enough ?
>>
>> Vincent Torri
>>
>> First, it seems that i have deleted your answers wh
ping2 :)
Vincent Torri
On Tue, Jan 4, 2011 at 8:24 AM, Vincent Torri wrote:
>
> Hey,
>
> Wasn't what i want (see below) clear enough ?
>
> Vincent Torri
>
> First, it seems that i have deleted your answers while deleting other
>> files. So I answer to my mail without your comments. Sorry for t
Hey,
Wasn't what i want (see below) clear enough ?
Vincent Torri
First, it seems that i have deleted your answers while deleting other files.
So I answer to my mail without your comments. Sorry for the inconvenience
(the archive will not display this mail as an answer to your mail)
On Mon,
Hey,
First, it seems that i have deleted your answers while deleting other
files. So I answer to my mail without your comments. Sorry for the
inconvenience (the archive will not display this mail as an answer to your
mail)
On Mon, 20 Dec 2010, Vincent Torri wrote:
* Vincent Torri wrote on
Hello Vincent,
* Vincent Torri wrote on Sat, Dec 18, 2010 at 08:52:59PM CET:
> I saw in the automake doc a support for yacc and lex. I looked in
> automake/am/ and saw 2 files, lex.am and yacc.am, which seem to
> allow that support.
>
> We have a program that tranforms .edc files into .edj files,
Hey,
I saw in the automake doc a support for yacc and lex. I looked in
automake/am/ and saw 2 files, lex.am and yacc.am, which seem to allow that
support.
We have a program that tranforms .edc files into .edj files, and we would
like to add similar support for that program.
Unfortunately,
Hello,
* Eric Blake wrote on Tue, Aug 24, 2010 at 06:47:51PM CEST:
> On 08/24/2010 10:42 AM, Joost Kraaijeveld wrote:
> >*** Since this library must not contain undefined symbols,
> >*** because either the platform does not support them or
> >*** it was explicitly requested with -no-undefined,
> >
[adding libtool]
On 08/24/2010 10:42 AM, Joost Kraaijeveld wrote:
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
It seems
On Tue, 2010-08-24 at 16:42 +0200, Joost Kraaijeveld wrote:
> Hi,
>
> I want to cross compile a library on Linux (Debian Sqeeeze AMD64) to
> Windows. On Linux both the static and shared libraries are build. On
> Windows just the static library is build. Should I do something speci
Hi,
I want to cross compile a library on Linux (Debian Sqeeeze AMD64) to
Windows. On Linux both the static and shared libraries are build. On
Windows just the static library is build. Should I do something special
to build a shared library, or should the same autotools configuration
build dll&#
* Adam Mercer wrote on Thu, Dec 31, 2009 at 12:24:45AM CET:
> On Wed, Dec 30, 2009 at 22:17, Adam Mercer wrote:
>
> > Just made this change and autoreconf no longer complains if compile
> > isn't available. Thanks!
>
> And it's started complaining again :-
On Wed, Dec 30, 2009 at 22:17, Adam Mercer wrote:
> Just made this change and autoreconf no longer complains if compile
> isn't available. Thanks!
And it's started complaining again :-(
I've tried running automake manually, with the verbose option:
automake: reading test
t;
> That's something I've been meaning to do for a while, but there have
> been more pressing matters to attend to.
Just made this change and autoreconf no longer complains if compile
isn't available. Thanks!
Cheers
Adam
named due to per-target compile flags, etc.
I'm not using any of these.
> Even in packages where the `compile' script is not deemed necessary, the
> rules might use '-c -o' if configure determined that GCC is used; that
> compiler is always assumed to allow this option
Hi Adam,
* Adam Mercer wrote on Wed, Dec 30, 2009 at 11:57:27AM CET:
> On one of my projects I'm running into an issue, only on certain
> platforms, where the compile script isn't available. e.g. on CentOS 5
>
> $ autoreconf
> test/Makefile.am: required file `gnus
Hi
On one of my projects I'm running into an issue, only on certain
platforms, where the compile script isn't available. e.g. on CentOS 5
$ autoreconf
test/Makefile.am: required file `gnuscripts/compile' not found
autoreconf: automake failed with exit status: 1
$
yet I have oth
Hi Ken,
Ken Perl writes:
> Hello,
>
> I have AM_PATH_GTK_2_0(1.3.5) in configure.ac and
> app_CPPFLAGS = @GTK_CFLAGS@
> app_LDADD = @GTK_LIBS@
> in Makefile.am
>
> the above works fine on Linux and compiles crossly a simple win32
> version on Linux, if I'd tra
Hello,
I have AM_PATH_GTK_2_0(1.3.5) in configure.ac and
app_CPPFLAGS = @GTK_CFLAGS@
app_LDADD = @GTK_LIBS@
in Makefile.am
the above works fine on Linux and compiles crossly a simple win32
version on Linux, if I'd transfer one -mwindows compile-link option
when cross-compiling, what d
i586-mingw32msvc-gcc works fine, I just install it from apt-get.
I upgraded automake to 1:1.11-1 and also upgrade autoconf on Debian
and now I can't reproduce my previous post issue anymore, thanks for
your help.
On Mon, Nov 30, 2009 at 3:32 AM, Ralf Wildenhues wrote:
> Hi Ken,
>
> * Ken Perl wr
Hi Ken,
* Ken Perl wrote on Sun, Nov 29, 2009 at 07:11:11AM CET:
> I may configure; make successfully on Linux, but when I tried to build
> it for win32 crossly on Linux, I have trouble, see below steps,
>
> ./configure --build i686-pc-linux-gnu --host i586-mingw32msvc
> make
> i586-mingw32msvc-g
Ken,
I got no errors following your example:
make all-am
make[1]: se ingresa al directorio `/home/alberto/testAutotools/ming'
i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT hello.o -MD -MP
-MF .deps/hello.Tpo -c -o hello.o hello.c
mv -f .deps/hello.Tpo .deps/hello.Po
i586-mingw32msvc-gc
Hi,
I created a very simple configure.ac with autoscan for the hello wold
program, and a very simple Makefile.am,
$cat Makefile.am
bin_PROGRAMS = hello
hello_SOURCES = hello.c
I may configure; make successfully on Linux, but when I tried to build
it for win32 crossly on Linux, I have trouble, se
> Here's a ping for Ralph.
I asked for his help and then I went and spelled his name wrong. My
apologies Ralf.
-DB
On Friday September 4th, 2009, Eric Blake wrote:
> According to David Byron on 8/14/2009 1:57 PM:
>
> > I'm not sure whether this is something I'm doing wrong
> > or something wrong with automake, autoconf or libtool.
> > At the moment I'm leaning
asking google for "gnu-make m2c" gave me the needed answers. Now my
files look like:
src/Makefile.am ###
moddir=/home/martin/opt/lib/gcc/i686-pc-linux-gnu/4.1.2/gm2
noinst_LIBRARIES = libVectorMath.a
libVectorMath_a_SOURCES = VectorMath.mod
l
src/Makefile
test/Makefile
doc/Makefile])
AC_OUTPUT
The problem I have is, that he doesn't use gm2 to compile the code but
tries to use the m2c modula-2 to c compiler. But this compiler isn't
ISO-standard compatible. So he can't compile it. I used grep to
ood question. We are in the process of modifying an existing
> autotools framework to meet new requirements. In the existing setup
> there were some custom m4 scripts that were executed in the
> cross-compile case (we need cross compilation only on special machines
> like IBM Blue Gene
Ralf Wildenhues wrote:
> Hello Christian,
>
> * Christian Rössel wrote on Tue, Apr 14, 2009 at 03:20:35PM CEST:
>> I have a cross-compile situation where I want to compile sources of a
>> subdirectory for the host system as well as for the build system. I pass
>> --hos
Hello Christian,
* Christian Rössel wrote on Tue, Apr 14, 2009 at 03:20:35PM CEST:
> I have a cross-compile situation where I want to compile sources of a
> subdirectory for the host system as well as for the build system. I pass
> --host, --build and CC_FOR_BUILD to configure. Then I
Hi,
I have a cross-compile situation where I want to compile sources of a
subdirectory for the host system as well as for the build system. I pass
--host, --build and CC_FOR_BUILD to configure. Then I have two
Makefile.am in distinct subdirectories, one has the statement
CC=$(CC_FOR_BUILD), the
On Sun, Sep 7, 2008 at 2:11 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * Steven Woody wrote on Sun, Sep 07, 2008 at 07:53:43AM CEST:
>> On Tue, Sep 2, 2008 at 2:35 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>> > Erm, have you tried
>> > CC=arm-linux-gcc ./configure
>> >
>> > yet?
>
>> If
* Steven Woody wrote on Sun, Sep 07, 2008 at 07:53:43AM CEST:
> On Tue, Sep 2, 2008 at 2:35 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > Erm, have you tried
> > CC=arm-linux-gcc ./configure
> >
> > yet?
> If I did that, I will get:
>
> loading cache ./config.cache
> checking host system ty
On Tue, Sep 2, 2008 at 2:35 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello Steven,
>
> * Steven Woody wrote on Sun, Aug 31, 2008 at 09:50:26AM CEST:
>> On Sun, Aug 31, 2008 at 11:21 AM, Ralf Wildenhues wrote:
>> >>
>> > Please try
>> > ./configure arm-linux
>> >
>> > which was IIRC the wa
Hello Steven,
* Steven Woody wrote on Sun, Aug 31, 2008 at 09:50:26AM CEST:
> On Sun, Aug 31, 2008 at 11:21 AM, Ralf Wildenhues wrote:
> >>
> > Please try
> > ./configure arm-linux
> >
> > which was IIRC the way to do it with Autoconf 2.13.
> >
>
> Yes, it is 2.13 automake, I found the informat
On Sun, Aug 31, 2008 at 11:21 AM, Ralf Wildenhues
<[EMAIL PROTECTED]> wrote:
> Hello Steven,
>
> * Steven Woody wrote on Sat, Aug 30, 2008 at 05:10:06PM CEST:
>>
>> For some reasons I need to cross-compile a tar-1.13, the target is ARM
>> and the build host is i
Hello Steven,
* Steven Woody wrote on Sat, Aug 30, 2008 at 05:10:06PM CEST:
>
> For some reasons I need to cross-compile a tar-1.13, the target is ARM
> and the build host is i686-pc-linux-gnu. The tar-1.13's source come
> with a configure, that seems generated from a ve
Hi,
For some reasons I need to cross-compile a tar-1.13, the target is ARM
and the build host is i686-pc-linux-gnu. The tar-1.13's source come
with a configure, that seems generated from a very old version of
automake. For recent automake version, I have success experience to
do cross-comp
Hi,
I want to use a Debian based mingw cross compiler to compile a library
that uses the pthreads-win32 package. I have created a symlink
libpthread.a -> libpthreadGC2.a.
I have two macros that appear to determine correctly if the pthread
package is available:
development_default=&
Automake doesn't really know how to deal with python. I have come across
a lot of cross compilation problems.
When cross compiling an app there is currently no way of determining
a) which python headers are suitable for the target platform.
b) what version of python is available on the tar
On 10/16/07, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On Tue, 16 Oct 2007, NightStrike wrote:
>
> > Where is $(COMPILE) documented? When should it be used? What does it
> > actually get set to?
>
> Read a generated Makefile and all secrets will be revealed
On 10/16/07, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On Tue, 16 Oct 2007, NightStrike wrote:
>
> > Where is $(COMPILE) documented? When should it be used? What does it
> > actually get set to?
>
> Read a generated Makefile and all secrets will be revealed.
On Tue, 16 Oct 2007, NightStrike wrote:
Where is $(COMPILE) documented? When should it be used? What does it
actually get set to?
Read a generated Makefile and all secrets will be revealed. Normally
you should not care about $(COMPILE) since Automake takes care of it.
Bob
On 10/16/07, Benoit SIGOURE <[EMAIL PROTECTED]> wrote:
> On Oct 16, 2007, at 10:05 AM, NightStrike wrote:
>
> > Where is $(COMPILE) documented?
>
> http://www.gnu.org/software/automake/manual/html_node/Program-
> variables.html#index-COMPILE-494
>
> > When sho
On Oct 16, 2007, at 10:05 AM, NightStrike wrote:
Where is $(COMPILE) documented?
http://www.gnu.org/software/automake/manual/html_node/Program-
variables.html#index-COMPILE-494
When should it be used?
When you want to "compile a C source file" (quoting the manual).
Maybe
Where is $(COMPILE) documented? When should it be used? What does it
actually get set to?
> -Ursprüngliche Nachricht-
> Von: Ralf Wildenhues [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 27. November 2006 21:45
> An: Jurzitza, Dieter
> Cc: automake@gnu.org; automake-patches@gnu.org
> Betreff: Re: Question on compile & test / automake version
> 1.9.6 / test yacc6.
Hello Dieter,
* Jurzitza, Dieter wrote on Wed, Nov 22, 2006 at 11:53:34AM CET:
> The point is:
> I cannot compile successfully (or, better to say, I cannot run
> yacc6.test successfully) if I am using
>
> make -j3
>
> The message that comes is "foo.h" and / or &qu
Dear Mr. Wildenhues,
dear listmembers,
after my yesterday's writing I found that I had had communicated a real
problem, but the wrong cause.
The point is:
I cannot compile successfully (or, better to say, I cannot run yacc6.test
successfully) if I am using
make -j3
The message that com
Dear listmembers,
when trying to build and test automake v 1.9.6 I keep stumbling over yacc6.test.
More specifically, starting in line 93:
**
$FGREP '(top_srcdir)/aux1/ylwrap' sub/Makefile.in
./configure
$MAKE
grep '#.*line.*foo.y' sub/foo.c
grep '#.*line.*bar.y' sub/bar.c
**
fa
Hello,
Thanks for the report.
* Jurzitza, Dieter wrote on Tue, Nov 21, 2006 at 03:41:14PM CET:
> when trying to build and test automake v 1.9.6 I keep stumbling over
> yacc6.test.
>
> More specifically, starting in line 93:
[...]
> fails saying foo.h would not be found.
Please go into the test
Hello,
Please remove automake@gnu.org from followups. This is an Autoconf
question. Thank you.
* shamju joseph wrote on Sat, Oct 28, 2006 at 12:23:54PM CEST:
>
> I want to cross compile one open source flash player
> ('gnash') for a Fusiv processor(ADI) based board. I'
1 - 100 of 196 matches
Mail list logo
