Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re: [Caml-list] CVS tracking and 3.08 testing #2912

Closed
vicuna opened this issue Jul 6, 2004 · 12 comments
Closed

Re: [Caml-list] CVS tracking and 3.08 testing #2912

vicuna opened this issue Jul 6, 2004 · 12 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Jul 6, 2004

Original bug ID: 2912
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Hi,
Just back from vacation, and I had problems compiling new 3.08 on our
SPARC/Solaris machines, though I compiled successfully on Linux. Has this been
reported yet, or should I fill out a bug report? Here is the tail end of the
"make world.opt" on solaris,

gmake[1]: Entering directory /home/bpr/apps/ocaml/yacc' gcc -O -DNDEBUG -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o closure.o closure.c gcc -O -DNDEBUG -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o error.o error.c gcc -O -DNDEBUG -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o lalr.o lalr.c gcc -O -DNDEBUG -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o lr0.o lr0.c gcc -O -DNDEBUG -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o main.o main.c gcc -O -DNDEBUG -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o mkpar.o mkpar.c gcc -O -DNDEBUG -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o output.o output.c gcc -O -DNDEBUG -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o reader.o reader.c gcc -O -DNDEBUG -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o skeleton.o skeleton.c gcc -O -DNDEBUG -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o symtab.o symtab.c gcc -O -DNDEBUG -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o verbose.o verbose.c gcc -O -DNDEBUG -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o warshall.o warshall.c gcc -O -DNDEBUG -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -o ocamlyacc closure.o error.o lalr.o lr 0.o main.o mkpar.o output.o reader.o skeleton.o symtab.o verbose.o warshall.o gmake[1]: Leaving directory /home/bpr/apps/ocaml/yacc'
cp yacc/ocamlyacc boot/ocamlyacc
cd stdlib; gmake COMPILER=../boot/ocamlc all
gmake[1]: Entering directory /home/bpr/apps/ocaml/stdlib' ../boot/ocamlrun ../boot/ocamlc -g -warn-error A -nostdlib ./Compflags
pervasives.cmi` -c pervasives.mli

Fatal error: cannot open pervasives.cmi
Fatal error: exception Misc.Fatal_error
gmake[1]: *** [pervasives.cmi] Error 2
gmake[1]: Leaving directory `/home/bpr/apps/ocaml/stdlib'
gmake: *** [coldstart] Error 2

On Thu, 1 Jul 2004, Xavier Leroy wrote:

To all OCaml users who track the CVS or are willing to beta-test:

We are progressing towards a release of OCaml 3.08, and at the same
time experimenting with a two-branch development model, one branch for
short-term bug fixes and the other for longer-term developments.

If this model turns out to work well, we hope it will make it easier
for users to benefit from bug fixes between major releases, and speed
up the release process.

Users who track the CVS sources from camlcvs.inria.fr are encouraged
to switch to the current release branch, which is labeled "release308".
This is the branch where we currently do bug fixes before release 3.08
and where we'll do post-release bug fixes if needed. It is currently
more up-to date than the main branch, which is the development branch,
and will remain so for a couple of months at least. To switch your
CVS checked-out sources to the release branch, just do

      cvs update -r release308

Users who are willing to beta-test the upcoming 3.08 release should
also get the sources from the "release308" branch of the CVS:

cvs -d ":pserver:anoncvs@camlcvs.inria.fr:/caml" checkout -r release308 ocaml

Now is a very good time to test and report bugs.

Thanks for your cooperation,

  • Xavier Leroy

To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

@vicuna
Copy link
Author

vicuna commented Jul 6, 2004

Comment author: administrator

Hi Jacques,
I believe we're using gcc-2.95, but that doesn't seem like where the problem
is. It is indeed a repeating problem though. I execute make world.opt, and
it just won't copile. I'll provide more detail later.

On Wed, 7 Jul 2004, Jacques GARRIGUE wrote:

From: brogoff@speakeasy.net

Just back from vacation, and I had problems compiling new 3.08 on our

SPARC/Solaris machines, though I compiled successfully on Linux. Has this been
reported yet, or should I fill out a bug report? Here is the tail end of the
"make world.opt" on solaris,

If there is really a problem, we need more details.
However I just checked now on solaris2.8 with gcc 3.3, and it compiles
without any problems.

Just make sure you execcute the following sequence
export LC_ALL=C
make clean
./configure
make opt.opt

Jacques

@vicuna
Copy link
Author

vicuna commented Jul 7, 2004

Comment author: administrator

From: brogoff@speakeasy.net

Just back from vacation, and I had problems compiling new 3.08 on our

SPARC/Solaris machines, though I compiled successfully on Linux. Has this been
reported yet, or should I fill out a bug report? Here is the tail end of the
"make world.opt" on solaris,

If there is really a problem, we need more details.
However I just checked now on solaris2.8 with gcc 3.3, and it compiles
without any problems.

Just make sure you execcute the following sequence
export LC_ALL=C
make clean
./configure
make opt.opt

Jacques

@vicuna
Copy link
Author

vicuna commented Jul 7, 2004

Comment author: administrator

It doesn't print anything at all

bpr@s-eng-2121[stdlib]$ uname -a
SunOS s-eng-2121 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Fire-280R
bpr@s-eng-2121[stdlib]$ ./Compflags pervasives.cmi
bpr@s-eng-2121[stdlib]$

On Wed, 7 Jul 2004, Xavier Leroy wrote:

../boot/ocamlrun ../boot/ocamlc -g -warn-error A -nostdlib ./Compflags pervasives.cmi -c pervasives.mli

Fatal error: cannot open pervasives.cmi
Fatal error: exception Misc.Fatal_error

As Jacques said, it works fine here (Sparc Solaris 9).

Could you please change to ocaml/stdlib and run

  ./Compflags pervasives.cmi

If it prints anything other than "-nopervasives", we have a shell
script portability problem...

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jul 7, 2004

Comment author: administrator

bpr@s-eng-2121[stdlib]$ ./Compflags pervasives.cmi
bpr@s-eng-2121[stdlib]$ sh -x ./Compflags pervasives.cmi

  • echo -nopervasives
    bpr@s-eng-2121[stdlib]$

I'll be busy for the rest of the afternoon, (evening for you!) so don't
interpret a lack of further response as impatience, I'll try to get back on
later (Pacific Standard Time)

On Wed, 7 Jul 2004, Xavier Leroy wrote:

It doesn't print anything at all

bpr@s-eng-2121[stdlib]$ uname -a
SunOS s-eng-2121 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Fire-280R
bpr@s-eng-2121[stdlib]$ ./Compflags pervasives.cmi
bpr@s-eng-2121[stdlib]$

This is getting really strange. It should always print something, if
only an empty line. And of course I don't have a Solaris 8 machine handy.
(Jacques, do you?)

If your patience hasn't been exhausted, could you also try the following?

sh -x ./Compflags pervasives.cmi

Thanks,

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jul 7, 2004

Comment author: administrator

../boot/ocamlrun ../boot/ocamlc -g -warn-error A -nostdlib ./Compflags pervasives.cmi -c pervasives.mli

Fatal error: cannot open pervasives.cmi
Fatal error: exception Misc.Fatal_error

As Jacques said, it works fine here (Sparc Solaris 9).

Could you please change to ocaml/stdlib and run

  ./Compflags pervasives.cmi

If it prints anything other than "-nopervasives", we have a shell
script portability problem...

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jul 7, 2004

Comment author: administrator

OK, I think I have it, the default system path at Artisan has /usr/ucb ahead
of /usr/bin, so I'm using /usr/ucb/echo, which has stupid behavior on
some -n stuff.

You just have to love this stuff :-(.

Thanks for the hints!

On Thu, 8 Jul 2004, Jacques GARRIGUE wrote:

From: brogoff@speakeasy.net

bpr@s-eng-2121[stdlib]$ ./Compflags pervasives.cmi
bpr@s-eng-2121[stdlib]$ sh -x ./Compflags pervasives.cmi

  • echo -nopervasives
    bpr@s-eng-2121[stdlib]$

That's getting extremely strange. The right command is excuted,
but without output. All the stranger as echo on Solaris is a shell
builtin command, that does not depend on your path. And aliases are
ignored for shell scripts.
I suppose the next step is trying
$ /bin/sh -c "echo -nopervasives"

Looking at the man page, I saw that the -n option to echo is enabled
when SYSV3 is set, but even in that case, there must be a space after
-n, so this cannot be the reason either.

This seems a problem in your environment, not in ocaml.
I couldn't reproduce it on the following machines:
SunOS suiren 5.8 Generic_108529-29 i86pc i386 i86pc
SunOS orion 5.8 Generic_117350-02 sun4u sparc SUNW,Sun-Blade-1500
SunOS milk 5.8 Generic_108528-29 sun4u sparc SUNW,Sun-Blade-1000

Jacques

bpr@s-eng-2121[stdlib]$ uname -a
SunOS s-eng-2121 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Fire-280R
bpr@s-eng-2121[stdlib]$ ./Compflags pervasives.cmi
bpr@s-eng-2121[stdlib]$

@vicuna
Copy link
Author

vicuna commented Jul 7, 2004

Comment author: administrator

It doesn't print anything at all

bpr@s-eng-2121[stdlib]$ uname -a
SunOS s-eng-2121 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Fire-280R
bpr@s-eng-2121[stdlib]$ ./Compflags pervasives.cmi
bpr@s-eng-2121[stdlib]$

This is getting really strange. It should always print something, if
only an empty line. And of course I don't have a Solaris 8 machine handy.
(Jacques, do you?)

If your patience hasn't been exhausted, could you also try the following?

sh -x ./Compflags pervasives.cmi

Thanks,

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jul 8, 2004

Comment author: administrator

On Thu, 8 Jul 2004, Jacques GARRIGUE wrote:

OK, I think I have it, the default system path at Artisan has /usr/ucb ahead
of /usr/bin, so I'm using /usr/ucb/echo, which has stupid behavior on
some -n stuff.

I don't understand.
For me /usr/ucb/echo does not behave this way (and it should not.)

suiren-tmp> /usr/ucb/echo -nopervasives
-nopervasives
suiren-tmp>

You're right! I don't understand either. But changing the path allowed me to
compile.

Moreover, according to the man page, echo is a builtin of sh, so
/usr/ucb/echo shouldn't be called anyway.

But, but, I can actually reproduce your problem:

suiren-tmp> env PATH=/usr/ucb:$PATH /usr/bin/sh -c "echo -nopervasives"
suiren-tmp>

Even weirder: if I make a symbolic link to /usr/ucb/echo in the first
directory in my path, the builtin echo is still used.
So it rather seems that the behaviour of the builtin echo depends on
the path. Crazy.

This looks like a bug in Solaris, no?

Yes, or some undocumented "feature". Defintely a Solaris only thing for me.
Linux worked fine.

-- Brian

@vicuna
Copy link
Author

vicuna commented Jul 8, 2004

Comment author: administrator

But, but, I can actually reproduce your problem:
suiren-tmp> env PATH=/usr/ucb:$PATH /usr/bin/sh -c "echo -nopervasives"
suiren-tmp>

This also "works" here on Solaris 9.

So it rather seems that the behaviour of the builtin echo depends on
the path. Crazy. This looks like a bug in Solaris, no?

I guess so, but we'll work around it (TM). I just "committed" a
trivial change to stdlib/Compflags whereas we do
echo ' -nopervasives'
(note the space!). That seems to clear things up.

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jul 8, 2004

Comment author: administrator

Solaris sh / echo madness. Workaround implemented 2004-07-08 by XL.

@vicuna vicuna closed this as completed Jul 8, 2004
@vicuna
Copy link
Author

vicuna commented Jul 8, 2004

Comment author: administrator

From: brogoff@speakeasy.net

bpr@s-eng-2121[stdlib]$ ./Compflags pervasives.cmi
bpr@s-eng-2121[stdlib]$ sh -x ./Compflags pervasives.cmi

  • echo -nopervasives
    bpr@s-eng-2121[stdlib]$

That's getting extremely strange. The right command is excuted,
but without output. All the stranger as echo on Solaris is a shell
builtin command, that does not depend on your path. And aliases are
ignored for shell scripts.
I suppose the next step is trying
$ /bin/sh -c "echo -nopervasives"

Looking at the man page, I saw that the -n option to echo is enabled
when SYSV3 is set, but even in that case, there must be a space after
-n, so this cannot be the reason either.

This seems a problem in your environment, not in ocaml.
I couldn't reproduce it on the following machines:
SunOS suiren 5.8 Generic_108529-29 i86pc i386 i86pc
SunOS orion 5.8 Generic_117350-02 sun4u sparc SUNW,Sun-Blade-1500
SunOS milk 5.8 Generic_108528-29 sun4u sparc SUNW,Sun-Blade-1000

Jacques

bpr@s-eng-2121[stdlib]$ uname -a
SunOS s-eng-2121 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Fire-280R
bpr@s-eng-2121[stdlib]$ ./Compflags pervasives.cmi
bpr@s-eng-2121[stdlib]$

@vicuna
Copy link
Author

vicuna commented Jul 8, 2004

Comment author: administrator

OK, I think I have it, the default system path at Artisan has /usr/ucb ahead
of /usr/bin, so I'm using /usr/ucb/echo, which has stupid behavior on
some -n stuff.

I don't understand.
For me /usr/ucb/echo does not behave this way (and it should not.)

suiren-tmp> /usr/ucb/echo -nopervasives
-nopervasives
suiren-tmp>

Moreover, according to the man page, echo is a builtin of sh, so
/usr/ucb/echo shouldn't be called anyway.

But, but, I can actually reproduce your problem:

suiren-tmp> env PATH=/usr/ucb:$PATH /usr/bin/sh -c "echo -nopervasives"
suiren-tmp>

Even weirder: if I make a symbolic link to /usr/ucb/echo in the first
directory in my path, the builtin echo is still used.
So it rather seems that the behaviour of the builtin echo depends on
the path. Crazy.

This looks like a bug in Solaris, no?

 Jacques

@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant