RE: [help-3dldf] failed to install 3DLDF-1.1.5.1

[Laurence Finston]

Hi Li,

> Next I run "make 3dldf" and get the error message
> ---------------------------------------------
> main.web(188): error: identifier "NO_SORT" is undefined
>   current_picture.output(default_focus,PERSP,1,NO_SORT);
>                                                ^

`NO_SORT' is declared in `namespace Sorting', so you either have to have
`using namespace Sorting;' in the scope where you use 
`NO_SORT', or you have to write `Sorting::NO_SORT'.

>  Because I don't understand if the \CWEB
> directory is
> the working directory, why we still need to set up another directory in
> configure command.

Because `make install' will create a `bin' subdirectory and put a copy of the
executable in it.  I don't remember where exactly, in `/usr/' or
`/usr/local/', I believe.  I don't have root privileges on the machine I use
to develop  3DLDF, so I'm not allowed to write to these directories.  Even if
one does, there's not much point to this, because one must rebuild the
executable to change one's drawing or drawings.  If you look at the directory
you specify as a prefix, you will find that there is a `\bin' directory with a
second copy of the executable in it.  
There doesn't seem to be any way to change this behavior;  it's built into
Automake.

This doesn't really matter, because in the development versions I'm making
available, and in future releases, there will be no need to rebuild the
executable for normal use.

> I also installed the newest gcc 3.4.2 on my node and included its lib path
> to
> LD_LIBRARY_PATH. By using "export CC=gcc" and "export CXX=g++3", (gcc3
> points to new gcc3.4.2)
> I try to install it and failed. Here is the error message
> --------------------------------------
> Making install in CWEB
> make[1]: Entering directory `/home/lli/down/temp/gh/3DLDF-1.1.5.1/CWEB'
> Makefile:559: warning: overriding commands for target `3dldf'
> Makefile:325: warning: ignoring old commands for target `3dldf'
> if g++3 -DHAVE_CONFIG_H -I. -I. -I.    -frepo -g -O2 -MT
> gsltmplt.o -MD -MP -MF ".deps/gsltmplt.Tpo" \
>   -c -o gsltmplt.o `test -f 'gsltmplt.cxx' || echo './'`gsltmplt.cxx; \
> then mv ".deps/gsltmplt.Tpo" ".deps/gsltmplt.Po"; \
> else rm -f ".deps/gsltmplt.Tpo"; exit 1; \
> fi
> gsltmplt.web: In function `Real System::get_second_largest(Real, bool)':
> gsltmplt.web:264: error: `bitset' undeclared (first use this function)
> gsltmplt.web:264: error: (Each undeclared identifier is reported only once
> for each function it appears in.)
> gsltmplt.web:264: error: `b' undeclared (first use this function)
> make[1]: *** [gsltmplt.o] Error 1
> make[1]: Leaving directory `/home/lli/down/temp/gh/3DLDF-1.1.5.1/CWEB'
> make: *** [install-recursive] Error 1
> ------------------------------------------

It's the same problem I described before, just a different library header.
If you got this far, I suppose you've got `ios' and `limits'.  Did you update
the standard library?  I don't know if installing the compiler does this
automatically.  Do you know where the header files are located on your system?
 Is there a `bitset' file there?  How about `bitset.h',
`Bitset', or some other variant?   Are you sure you're loading the GNU
standard library?  You say you've 
"included its lib path  to LD_LIBRARY_PATH".  Do you mean you appended it?  If
so, you are probably searching the path for the Intel standard library first,
and you might be finding something that's causing this to fail.  This wouldn't
surprise me, because DECs `bitset' differs from GNU's, too.  I would actually
expect this to fail sooner, but one never knows.  On the other hand, you say
that you're able to build the executable with the Intel compiler.  

I think the easiest way to try to figure out what the problem is, is to write
a trivial C++ program using a bitset and try to get it to work. 

I'm not sure using environment variables the way you describe, i.e.,
executing "export CC=gcc" and "export CXX=g++3",
is a good idea.  I run Autoconf to generate `configure', which is included in
the distribution.  On other people's systems, like yours, `configure'  tests
the system and sets environment variables which are used for generating the
`make' files from the `Makefile.in' files, which are also included in the
distribution.   The behavior of `configure' may or may not be affected by the
environment variables you are setting and exporting.  I think it would be
better to give GCC its canonical names.  If you can't do this, I vaguely
recall a shell command called `alias'.  I'm writing this on a Windows PC, so I
can't check whether this would help.  Or perhaps you could try using a
symbolic link.  

Unless you have a particular reason for wanting to use 1.1.5.1, I recommend
using my development versions, collectively numbered 1.2.0.0.  If you need to
be able to use all of the functionality of 3DLDF right now, then you'll have
to use 1.1.5.1.  However, it's already possible to access most of 3DLDF's
functionality with 1.2.0.0, and I'm "filling in the gaps" as quickly as I can.
  Once I make an official release, 1.1.5.1 will be obsolete.   It's still
worth learning if you're interested in the implementation, though;  while I've
added quite a bit, I haven't changed what was already present that much.   It
is a lot more fun to use 3DLDF without having to recompile and relink over and
over again.

On the other hand 1.1.5.1 is easier to build, i.e., there are fewer things
that can go wrong, so you might want to try to get it to build using GCC
before trying to build 1.2.0.0.

Laurence