I'm facing a problem installing graphviz 2.29 oj FreeBSD system.
./configure works fine but after make i see this:
sftable.c:262: error: 'ptrdiff_t' undeclared
I'm not familiar to FreeBSD so i don't know what to do with this issue.
It seems to me that it's a known bug (http://www.graphviz.org/bugs/b1019.html) but there's no answer.
Please, help!
ps: gcc version 4.2.1 20070719
FreeBSD 7.3-RELEASE-p2
One way to install software that is newer then the port's version is to change the port's version (using graphviz as example):
% cd /usr/ports/graphics/graphviz
Edit the Makefile and change PORTVERSION to match the version you want. Comment any PORTREVISION and leave PORTEPOCH alone.
% sudo make makesum
% sudo make
In a lot of cases this simply works, because the patches that the port maintainer applies to make things work, don't always make it upstream timely. If this don't work and your knowledge is of the ports system is minimal, you might want to stop, if not or eager to learn, then read the errors and try to resolve them.
Well, then try to add this line:
#include <stddef.h>
at the top of sftable.c file.
Related
Since I installed according to the guide here on wsl2 ubuntu 20.04, I've been having errors related to libstc++.so.6, specifically GLIBCXX_3.4.26 not found (required by ...) where ... refers to different files within /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/ ending in .so, .so.1, .so.6 and so on (for instance, when running paraFoam the error would appear with respect to about 20 such files). I am able to successfully visualize the cavity tutorial (in paraview installation on windows).
I could get the errors to go away by doing what the user laborg suggested on Jan 4 for a similar problem with julia (see here), specifically copy libstdc++.so.6 from /usr/lib/x86_64-linux-gnu to /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/.
The questions is whether this copy-paste solution is recommended; will it come back and haunt me later? Is the libstdc++.so.6 from system installation going to be an issue if used in the lib64 folder of openfoam?
An additional info concerning openfoam installation, foamInstallationTest shows *not installed* errors against flex, wmake, gcc, g++, icoFoam and *critical error* for gcc, g++, icoFoam; but I as given here, foamInstallationTest is not meant for installation from the tar file. Openfoam installation seems to be alright based on the running of the cavity tutorial.
ok, please don't do copy past operation to solve this problem. The error means that you haven't installed the pre request libraries in your ubuntu. It seems that you have missed the first step in the tutorial.
It is not recommended but it will not hurt as long as the GLIBC versions returned from this command
strings /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6 | grep GLIBC
are a subset of the GLIBC versions from this command.
strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBC
which was no doubt the case for your Ubuntu setup.
A less risky route would be to redirect the soft link /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6 to point to your other libstdc++.so.6 (that way you retain both versions)
ln -sf /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6
Then, if you hit an issue, you can always reset the link back to its original target. Of course /usr/lib/x86_64-linux-gnu/libstdc++.so.6 is itself a soft link, but you can point to it all the same or you can point to its target.
I believe the issue you are hitting is a derivative of the one mentioned here https://www.cfd-online.com/Forums/main/229027-persistence-glibcxx_3-4-26-not-found.html, which would point towards the fact that it is not an installation error on your part but an issue related to the packaging of the OpenFoam binaries. I agree it would screw up the wsl2 setup owing to the way OpenFoam prepends everything to paths. Of course the safest route is to compile from source using the Ubuntu system's gcc and thereby bypass the ThirdParty.
Seeing as you are using Ubuntu in the WSL instance, could also just install the Ubuntu package directly:
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
This problem comes from this line in the tutorial:
echo "source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc" >> ~/.bashrc
This will point to OpenFOAM's libstdc++ everytime you open a terminal (or start a WSL2 session). If your workflow is not related to OpenFOAM, that can be an issue. If you remove or comment that line in your ~/.bashrc things should get back to normal. You can use nano in WSL2.
nano ~/.bashrc
Then comment:
#source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc
However, as OpenFOAM uses that bashrc, you will need to source the OpenFOAM bashrc in each terminal before using openFOAM.
source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc
My personal choice is to keep that line commented and, if I have a long work session using OpenFOAM, I just use nano to uncomment it, so every shell that I open works without sourcing again.
There are more elegant or complex approaches, but I prefer this one.
This answer should be valid with the 2006 version too, the link you shared points to 2012, so I guess they just updated the tutorial. If you installed 2006, just make sure when you source comment/uncomment to use the correct name.
In the same manner, if you followed another tutorial with another tool and sourced another library, you may experience issues.
Just start by taking a look at your bashrc and cleaning it.
when I am doing ./configure in opensolaris in an attempt to install software. I've got the following error:
error:C compiler cannot create executables
Then I check up on the net and find its due to a missing module call gcc-lib6-dev. But how can I install it?
Sounds like you found an answer for a completely different OS that doesn't apply to opensolaris (lib6 sounds like an old Linux release). Look in the generated config.log
for more detailed error messages that give better information as to the actual problem.
It's late and I should go to bed and maybe that's why I can't figure this out. I'm on a fedora-13 machine and I just ran
yum install gambit-c
I installed it because I want to follow along in a schemed text book.
but now that it's installed, how do I start the scheme interpreter??
It looks from the RPM listing that the binaries are named gsi, gsix, and gsc, all in /usr/bin. I suspect that gsi is the interpreter.
For more details, there's also the manual entry for gsi.
BTW: I don't know about the Fedora RPM, but I found that the Ubuntu repository's Gambit-C was quite outdated (4.0-ish), with missing features like simple compilation of stand-alone executables. The most recent version is 4.6. If your RPM's version is a few decimal places behind, I'd suggest just installing from source; it's a pretty standard configure -> make -> make install sequence. Just remember the following option when running configure:
./configure --enable-single-host
This speeds things up quite a bit.
I'm new to NX OSes, actually MacOS, and when I try to build sources with make and makefiles, I never can.
I try to run make, even try to run it passing the makefile as an argument, but all I get is "There's nothing for make to do"
Can you point me to a tutorial, reference, or something ?
This one is excellent.
(You can also read some criticism to round your knowledge.)
(If after reading these, you want to try cmake, then you want to go here. It works perfectly on Mac OS X.)
Generally if you're trying to install from a tarball there will be a file named README or INSTALL with installation instructions. Usually all you have to do is run from the terminal
./configure
make
sudo make install
It's generally possible to set options for compilation by adding flags to ./configure, to see what they are run
./configure --help
Here is a tutorial to help you get started.
Just remember to use tabs instead of spaces when indenting lines in the makefile :)
My attempts to install modperl under the default vanilla Leopard Apache 2 have failed and all I can find online are variations on this:
I would like if possible not to rely on MacPorts or Fink, though if they can be made to work with the default Apache 2 install that would probably be ok.
Macports has it (think apt-get and the likes on linux, but on OS X)
(you can see it listed here)
Haven't installed myself though....
Why not just give up and build/install your own or port versions of perl, apache2, and mod_perl2? Probably easier than fighting with it. (Worked for me.)
(as per comment)
Mmmkay! Sorry, I didn't intend that to be snarky or imply that it's not a valid question. I guess I'll delete this (if I can.) Would it be useful to edit the question to add your rational rationale for not having a separate installation?
Get the latest mod_perl and set the following var:
export ARCHFLAGS="-arch x86_64"
Compile/install as usual.
Taken from this post, "Building mod_perl2 on Leopard" which also links to further details on how to get Apache2::Request (libapreq) working as well.
-
(Not that I've been able to test it since I'm personally back on Tiger running Apache 1.3!)
(And let's see if stackoverflow manages to lift this answer to the top since it is the only "correct" answer)
I asked a very similar question a few days ago and got some good answers:
"How do I use a vendor Apache with a self-compiled Perl and mod_perl?"
The mc ports install of mod_perl tries to install apache 1.3 even if you specify just the mod perl, so thats not a good option.
Try this:
http://www.unibia.com/unibianet/node/32