Re: [edlug] differences g++ 2.95 and 3.2

[Mark de Vries <m.a.devries@xxx.xxx.xxx>]

Finally I got Blitz and gcc-3.2 working, it turned out that some overloaded 
operator functions for the TinyVector class had been moved out of the 
TinyVec.h header and put into TinyVec-et.h in Blitz++ version 0.7. I first 
thought the problem was with a difference gcc handed overloaded operators, 
but after I changed the headers everything compiled without a problem.

the standard ./configure --with-cxx=........., make ,make install procedure 
does not work for Redhat, but I found a recent rpm here: 
http://ptweb.op.ph.ic.ac.uk/~graceej/sw/

Many thanks for all helpfull suggestions,

Mark

On Wednesday 28 April 2004 21:27, Alistair K Phipps wrote:
> On Wed, 28 Apr 2004 17:12:59 +0100
>
> Mark de Vries <m.a.devries@xxx.xxx.xxx> wrote:
> > I do not understand programs
> > like autoconf, and make etc. , so I would not know how to install a
> > package into my user source tree, but I guess I can help the compiler to
> > find the libraries by making symlinks in the /usr/includes/ directory. IS
> > that right?
>
> Installing a program or library into your user source tree by
> compiling it from the original source is generally straightforward
> if it uses autoconf.  Usually all you have to do is run:
>
> ./configure --prefix=$HOME
>
> instead of ./configure ... where $HOME is your home directory (i.e.
> where you want the software installed).  It will be installed into
> bin/, lib/, man/ directories under your home directory.  I suggest
> specifying the full pathname as some configure scripts will fail if
> you use the ~ abbreviation.
>
> You can then add $HOME/bin into your PATH so you can run programs
> without having to specify where they are.  You also have to export
> LD_LIBRARY_PATH=$HOME/lib so that the linker looks in your personal
> lib directory for (shared) libraries.  You can probably do something
> similar to add the man directory to the search path for man pages but
> I've never bothered.
>
> If your project is non-trivial, you can do the install into your
> project's subdirectory, add the library source into your project's
> version control and then your project and its dependencies are in
> source control.  This gives you everything you require to successfully
> build and execute your project under your control.
>
> BTW... though usually the above configure magic is all you need, some
> software authors like to make things difficult, and you might have to
> poke around the "configure" file to find to the magic you need.  As a
> software author on Linux you will eventually have to get at least a
> rudimentary understanding of GNU make and autoconf!  Luckily the
> manual for make is online and is quite good and easily understandable.
> The manual for autoconf is also online and though I'm sure it's good
> for someone wanting to write their own configure scripts, it's not
> that readily accessible to someone just poking around someone else's
> configure file, but luckily they're self-explanatory in general.
>
> Having said all the above, what I said about building the libraries
> for yourself was said because I thought you were writing programs and
> would already know all about make and autoconf.  Building libraries
> for yourself in this way might not be the best way to proceed unless
> you don't mind a steep learning curve, though I'm sure it'd stand you
> in good stead for future work.  Given your situation, the good
> ideas others provided you with (like solving errors one at a time)
> would probably be the best thing to do!
>
> Good luck once again,
>
> Alistair
> -
> ----------------------------------------------------------------------
> You can find the EdLUG mailing list FAQ list at:
> http://www.edlug.org.uk/list_faq.html

-
----------------------------------------------------------------------
You can find the EdLUG mailing list FAQ list at:
http://www.edlug.org.uk/list_faq.html