gcov-iov creates a gcov-iov.h which has a version number
which changes when I change MVS versions. So I am
thinking of updating gcov-iov.c so that when the target is
MVS, it generates a more fixed format.
I don't see how the generated number depends on the MVS
version ... It is supposed to
On 11/14/2009 12:27 PM, Paul Edwards wrote:
So what I have done is get the compiler to fail on any missing
prototype. I think perhaps we need to have a generic gcc or
autoconfigure option called config by prototype. MVS is just
one instance where you might wish to do it this way. Other
ports
Paul Edwards wrote:
gcov-iov creates a gcov-iov.h which has a version number
which changes when I change MVS versions. So I am
thinking of updating gcov-iov.c so that when the target is
MVS, it generates a more fixed format.
I don't see how the generated number depends on the MVS
version
Ok, I've now reached a new milestone - the mshort.h which
redefines all the long names into ZZZ_123 etc is now
automatically generated as part of the build process.
The libiberty and gcc aren't split yet, but I'll probably defer
that to gcc 4, and see if I can simply reproduce what I have
with
Well, the configure process should result in the variable LIBOBJS
in the generated libiberty Makefile to be set to list of objects
containing implementations of replacement system routines.
So if you do not have HAVE_STRCASECMP in config.h, you should
have been getting strcasecmp.o in LIBOBJS
* Paul Edwards wrote on Sat, Nov 14, 2009 at 09:51:39AM CET:
Well, the configure process should result in the variable LIBOBJS
in the generated libiberty Makefile to be set to list of objects
containing implementations of replacement system routines.
So if you do not have HAVE_STRCASECMP in
LIBOBJS includes a strcasecmp.s$U.s
That suffix is certainly strange-looking though. I checked in
config.log and I can see that it automatically detected that
my object code has a .s extension, which is basically
correct given that I forced the -S option.
Why do you pass -S in the compiler
Ok, now I have some results from the auto-compile-script-generation.
I got it to work, but it required some manual corrections.
First of all, I got link errors, because sched-ebb etc were trying
to call various functions, but those functions were not being
compiled in because INSN_SCHEDULING
Paul Edwards wrote:
First of all, I got link errors, because sched-ebb etc were trying
to call various functions, but those functions were not being
compiled in because INSN_SCHEDULING was not defined
(that's my quick analysis, anyway). So I just grepped those
files out of the source list.
Paul Edwards:
1. I think my unixio.h, which has a stack of POSIX functions
that need to be there (mkdir, pwait, open, fileno etc), needs to
be considered honorary ansi (after all, so much code assumes
that they exist) and get included in ansidecl, with unixio.h
living in include, and
Next, a stack of libiberty files were not compiled - strcasecmp,
vasprintf, asprintf, getpagesize, strdup. I don't know why this
would be the case, because e.g. HAVE_STRCASECMP is
not defined. Anyway, I added them to the source list manually,
and with a script, awk and m4, I was able to produce
Paul Edwards wrote:
The thing is, I already know it has detected that I don't have
strcasecmp. That's why it doesn't have HAVE_STRCASECMP
defined in the config.h. You are right that I don't have a linker,
but the compile with error-on-no-prototype is working fine - I
can see the result in
Well, I have good news to report. The restructuring was a success.
That means with those 30-odd changes to the configure scripts, I
was able to get an auto-host.h built that allowed me to take the
generated source and compile it with my own scripts as per
normal.
There's still a stack more
Hello Paul,
* Paul Edwards wrote on Thu, Nov 12, 2009 at 03:02:59PM CET:
Well, I have good news to report. The restructuring was a success.
That means with those 30-odd changes to the configure scripts, I
was able to get an auto-host.h built that allowed me to take the
generated source and
* Paul Edwards wrote on Thu, Nov 12, 2009 at 03:02:59PM CET:
Well, I have good news to report. The restructuring was a success.
That means with those 30-odd changes to the configure scripts, I
was able to get an auto-host.h built that allowed me to take the
generated source and compile it with
I've been having fantastic success building gcc. I have got it
to iterate through the entire build (as far as I can tell) now.
Then finally I ran into an internal compiler error which I haven't seen
before. One of the gcc options must have triggered something off.
Perhaps it was
This means that if your GCC source tree resides in a directory, say,
~/gcc-src
you should *not* run ./configure while in ~/gcc-src. Instead, you
should create a second, empty directory
~/gcc-build
(which is not a subdirectory of ~/gcc-src), and run
../gcc-src/configure ...
while in
As to the pex-unix.c, you certainly should provide a MVS-specific
version of the PEX callbacks. They are selected in configure.ac:
# Figure out which version of pexecute to use.
case ${host} in
*-*-mingw* | *-*-winnt*) pexecute=pex-win32.o ;;
*-*-msdosdjgpp*)
Paul Edwards mutazi...@gmail.com writes:
The next thing I hit was that genmodes didn't compile because
there were conflicts between the strsignal function in the
Linux include files and the system.h. Looking at the system.h,
it was including things in because it thought that the prototypes
Paul Edwards wrote:
Ok, perhaps this error was because when I hit errors in intl,
which I've never used before, I just went to the gcc directory and
did a make.
Regardless, I added a stack of touch xxx.o in the intl directory
after the failure of the first make, which allowed me to do a
If you use --disable-nls on the configure line, the intl directory
should be skipped ...
Ok, that's working.
The next thing I hit was that genmodes didn't compile because
there were conflicts between the strsignal function in the
Linux include files and the system.h. Looking at the system.h,
Paul Edwards wrote:
Are you running the top-level configure? (If you run a
subdirectory configure, e.g. the one in gcc/, directly,
things may not work correctly.)
Yes I am.
One other thing I did - I compiled the cross-compiler, and installed it.
Then I wiped out the directory and
Hi Ulrich. I've had considerable success in this process. I've
now reached the point where I seem to have a correctly
generated config.h in libiberty and correct auto-host.h in gcc,
which is one of the aims in order to get an eventual link on
MVS.
However, it meant that I could look at the
Paul Edwards wrote:
Hi Ulrich. I've had considerable success in this process. I've
now reached the point where I seem to have a correctly
generated config.h in libiberty and correct auto-host.h in gcc,
which is one of the aims in order to get an eventual link on
MVS.
OK, good to hear
Hi Ulrich.
I'll try out some of those things. I have some initial
comments.
Hmmm, the access() use probably needs to be guarded by a configure
check. Or else you might provide a MVS-specific implementation of
access (if that is possible), and compile it into libiberty by
providing an
Paul Edwards wrote:
Maybe a more generic way to work around the missing assembler and linker
would be to provide dummy scripts i370-mvspdp-as
I created one of them, but as far as I can tell it didn't pick it up.
Ah, you'll probably have to re-run configure and rebuild the cross compiler.
.../configure --target=i370-mvs --prefix=... --with-sysroot=... \
--enable-languages=c
where prefix points to the directory where the cross-compiler
should be installed, and sysroot points to the directory where
the MVS libraries and header are installed.
Ok, I used
Paul Edwards wrote:
Ok, I used
../configure --target=i370-mvspdp --prefix=/devel/mvscross
--with-sysroot=/devel/mvshead
--enable-languages=c
plus make and make install
then I went to
mvscross/bin and renamed i370-mvspdp-gcc to i370-mvspdp-xxx
and replaced it with a script
Huh. I've never seen this before. Is this with your patches to
generate a single executable or without?
My patches are applied, but shouldn't be activated, because
I haven't defined SINGLE_EXECUTABLE.
I could try taking it back to raw 3.4.6 though and see if that has
the same problem.
Would you be able to give me the two suggested configure
commands so that I can find out the answer to the above, one
way or another?
For step 2 (building the cross-compiler), you'd need something
along the lines of
.../configure --target=i370-mvs --prefix=... --with-sysroot=... \
Paul Edwards:
The failure (on 3.4.6, but not on 3.2.3) is that after the successful
build, when I do an xgcc -S, it produces the assembler file, and then
hangs. I traced this to gcc.c which was in a loop doing this:
pid = pwait (commands[i].pid, status, 0);
getting a return of 0 all
The failure (on 3.4.6, but not on 3.2.3) is that after the successful
build, when I do an xgcc -S, it produces the assembler file, and then
hangs. I traced this to gcc.c which was in a loop doing this:
pid = pwait (commands[i].pid, status, 0);
getting a return of 0 all the time, while the
Paul Edwards wrote:
Huh. I've never seen this before. Is this with your patches to
generate a single executable or without?
My patches are applied, but shouldn't be activated, because
I haven't defined SINGLE_EXECUTABLE.
I could try taking it back to raw 3.4.6 though and see if that
Paul Edwards wrote:
Would you be able to give me the two suggested configure
commands so that I can find out the answer to the above, one
way or another?
For step 2 (building the cross-compiler), you'd need something
along the lines of
.../configure --target=i370-mvs --prefix=...
Hi,
On Sun, 4 Oct 2009, Paul Edwards wrote:
With 3.4.6, I have a script called compile, which looks like this:
call stdcomp alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp bb-reorder.c
.../configure --target=i370-mvs --prefix=... --with-sysroot=... \
--enable-languages=c
Thanks Ulrich. That's very different from the concept I had of
how the build process was meant to work.
Ignoring the cross stuff, if this is all you need I would suggest calling
make in the
Hi,
On Tue, 6 Oct 2009, Paul Edwards wrote:
Thanks Michael. That's exactly the sort of thing I was after. Just
one thing - I'll need more than cc1. I need the files that normally
go into gcc as well. So a combination of those two sets of source,
so that I can get a single standalone
Paul Edwards mutazi...@gmail.com writes:
* Copy header files and libraries from the host (MVS).
That's fine. And use the --with-root option of configure to get
them used?
--with-sysroot, yes.
I have been trying combinations of --prefix and --with-sysroot, and
--with-build-sysroot, but
* Copy header files and libraries from the host (MVS).
That's fine. And use the --with-root option of configure to get
them used?
--with-sysroot, yes.
I have been trying combinations of --prefix and --with-sysroot, and
--with-build-sysroot, but it is still insisting that I have an
Paul Edwards wrote:
I'm not sure whether to call MVS a target or host.
Maybe it helps to take a step back and look at how the process
of initially getting a compiler for a system B built, starting
on an existing system A, usually works.
Each of the following steps can be identified by three
In step 3, configure will use the A-B cross-compiler (from step 2)
to do the trial compiles. This compiler, if built correctly, will
use host *B* header files and libraries from its sysroot, and thus
configure will detect properties of system *B* (which again is correct,
as in step 3, host ==
Paul Edwards mutazi...@gmail.com writes:
* Configure gcc as a cross-compiler.
So this would not be considered a Canadian Cross after all,
and with configure I only change the target, not the host?
The end result is a Canadian Cross, but the first step in a typical
build of a Canadian Cross
* Configure gcc as a cross-compiler.
So this would not be considered a Canadian Cross after all,
and with configure I only change the target, not the host?
The end result is a Canadian Cross, but the first step in a typical
build of a Canadian Cross is a cross-compiler.
Ok.
* Write a
I tried again but I'm not making much progress.
Maybe I need to go further than Canada, let's say Alaska.
1. First I need to use my current build machine, Linux,
to first of all convert the i370.md into insn*.c files, then
generate an xgcc. The xgcc would be capable of producing
i370 code so
Paul Edwards mutazi...@gmail.com writes:
1. First I need to use my current build machine, Linux,
to first of all convert the i370.md into insn*.c files, then
generate an xgcc. The xgcc would be capable of producing
i370 code so long as I use the -S option. It doesn't really
matter how this
Hi Ian, thanks for your reply.
1. First I need to use my current build machine, Linux,
to first of all convert the i370.md into insn*.c files, then
generate an xgcc. The xgcc would be capable of producing
i370 code so long as I use the -S option. It doesn't really
matter how this xgcc was
2. If the normal way to do things is to parse the make -n output
with perl etc, that's fine, I'll do it that way. I was just wondering
if the proper way was to incorporate the logic into a Makefile
rule and get that rule repeatedly executed rather than just
having a simple echo. It seems
I am happy to construct all of this on a Unix system with the various
tools (m4 etc) available.
But from the Unix system, I need to be able to generate the
above very simple compile script, which is a precursor to creating
very simple JCL steps (trust me, you don't want to see what
ST2CMP
I am happy to construct all of this on a Unix system with the various
tools (m4 etc) available.
But from the Unix system, I need to be able to generate the
above very simple compile script, which is a precursor to creating
very simple JCL steps (trust me, you don't want to see what
ST2CMP looks
Paul Edwards mutazi...@gmail.com writes:
the gcc build system working. Trying to bootstrap gcc there seems
like a lot
of pain for no real benefit.
The effort is mostly in the Canadian Cross. The changes to get it to
bootstrap from that point are relatively small.
I think you are
On Thu, Oct 1, 2009 at 11:59 AM, Paul Edwards mutazi...@gmail.com wrote:
But from the Unix system, I need to be able to generate the
above very simple compile script, which is a precursor to creating
very simple JCL steps (trust me, you don't want to see what
ST2CMP looks like). Note that
David Edelsohn wrote:
On Thu, Oct 1, 2009 at 11:59 AM, Paul Edwards mutazi...@gmail.com wrote:
But from the Unix system, I need to be able to generate the
above very simple compile script, which is a precursor to creating
very simple JCL steps (trust me, you don't want to see what
ST2CMP
the gcc build system working. Trying to bootstrap gcc there seems
like a lot
of pain for no real benefit.
The effort is mostly in the Canadian Cross. The changes to get it to
bootstrap from that point are relatively small.
I think you are underestimating the work involved.
? Note that I
What is the best way to go from this:
Makefile:
C_AND_OBJC_OBJS = attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o
c-typeck.o \
c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o \
C_OBJS = c-lang.o stub-objc.o $(C_AND_OBJC_OBJS)
OBJS-common = \
^Iinsn-attrtab.o \
On 09/30/2009 08:00 AM, Paul Edwards wrote:
What is the best way to go from this:
Makefile:
The easy way to convert a Makefile to a shell script is make -n. That
will print out all of the commands that make would run. From there it's
a Mere Matter of Programming to have perl (or whatever)
What is the best way to go from this:
Makefile:
The easy way to convert a Makefile to a shell script is make -n. That
will print out all of the commands that make would run. From there it's a
Mere Matter of Programming to have perl (or whatever) edit that down into
your JCL scripts.
Hi
Paul Edwards mutazi...@gmail.com writes:
2. If the normal way to do things is to parse the make -n output
with perl etc, that's fine, I'll do it that way. I was just wondering
if the proper way was to incorporate the logic into a Makefile
rule and get that rule repeatedly executed rather
On Wed, 30 Sep 2009, Ian Lance Taylor wrote:
Paul Edwards mutazi...@gmail.com writes:
2. If the normal way to do things is to parse the make -n output
with perl etc, that's fine, I'll do it that way. I was just wondering
if the proper way was to incorporate the logic into a Makefile
58 matches
Mail list logo
