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
port
On 11/13/2009 12:43 PM, Paul Edwards wrote:
I normally define PREFIX in a
common header file. However, this caused a conflict between
prefix.c and regex.c which both try to use this keyword.
regex.c is forked from anything else, so I don't think a patch changing
PREFIX to FUNC_PREFIX will hav
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 dep
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
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 compil
* 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_STRCA
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:
> 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
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:
> 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 u
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 l
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 was
* 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
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
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 work
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 -Wwrite-string
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 ~/gcc-build
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 dir
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:
> 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
"Paul Edwards" 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
> didn't exist.
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*) pexecute=pex-
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 EXTRA_
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'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 aut
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 compi
../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 that does:
i370-mvspdp-xxx -S $*
Maybe a more g
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
.../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
../configure
> 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.
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 se
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 pr
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
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=... \
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 e
.../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 r
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-reor
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=... --with-s
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 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 sy
* 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
fputs_unl
"Paul Edwards" 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
* 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 cross
"Paul Edwards" 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 is a cross-com
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 cr
"Paul Edwards" 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 xgcc was c
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 lo
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 the JCL has the filenames
truncated to 8 characters, listed twice, uppercased, a
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 ha
David Edelsohn wrote:
On Thu, Oct 1, 2009 at 11:59 AM, Paul Edwards 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
On Thu, Oct 1, 2009 at 11:59 AM, Paul Edwards 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 the JCL ha
"Paul Edwards" 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 underestimating th
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 l
> 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
> S
> 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 s
On Wed, 30 Sep 2009, Ian Lance Taylor wrote:
> "Paul Edwards" 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
"Paul Edwards" 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 than just
> havin
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
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
60 matches
Mail list logo
