I have installed dmd and ddt as instructed:
DMD64 D Compiler v2.066.0
Copyright (c) 1999-2014 by Digital Mars written by Walter Bright
Documentation: http://dlang.org/
but when I create a dub project in eclipse, I dot an error that says standard libray not found:
(source: p.im9.eu)
any ideas?
OS: Mac OSX 10.9
Eclipse: 4.4
DDT: 0.10.2
I've also posted a temporary workaround in the discussion group (link):
# cd /usr/share/dmd
# mkdir dummy
# mkdir dummy/bin
# touch dummy/bin/dmd
# launchctl setenv DUB_COMPILERS_PATH /usr/share/dmd/dummy/bin
# killall Dock
Note that the DUB_COMPILERS_PATH variable shouldn't point to the binary itself, it acts like an additional PATH variable, i.e should contain bin dirs.
To make this survive a reboot, add the launchctl line to /etc/launchd.conf:
launchctl setenv DUB_COMPILERS_PATH /usr/share/dmd/dummy/bin
You might need to create it if it doesn't already exist.
This seems to be a reported bug of DDT:
https://github.com/bruno-medeiros/DDT/issues/75
Basically, it boils down to the directory structure of the installed dmd. As they are many distributions and many installers, each one with its own convention, DDT missed some.
They should be added and recognized shortly, in the pending release.
Please follow the reported issue on github/DDT page.
Yes, I know this thread is really old, and yes DDT seems to be no longer in development.
However, for those of us who are new to D, Eclipse and DDT, and relatively new to using Linux (I'm using Mint 19.3), I have the following solution which worked for me. No doubt this is common knowledge somewhere, but I had to scratch around quite a lot to discover this. (Of course, your dmd version number may be different.)
Note that dub is automatically installed along with dmd in:
$HOME/dlang/dmd-2.090.1/linux/bin64/dub
The command
source ~/dlang/dmd-2.090.1/activate
will modify the $PATH variable to allow access to the compiler.
NOTE that this only changes the path for the shell where the command is issued... and only for the current session!
If you want the path change to be permanent (who doesn't?), add the following to ~/.profile using a text editor, e.g. nano ~/.profile or xed ~/.profile , etc.:
# Add dlang dmd compiler path
if [ -d "$HOME/dlang/dmd-2.090.1/linux/bin64" ] ; then
PATH="$HOME/dlang/dmd-2.090.1/linux/bin64:$PATH"
fi
This corrects the Eclipse error:
"D Standard Library [Error: none found]"
in the Project tree, and also allows dub to be run from any directory, e.g. from a terminal.
HTH.
Related
I have met a problem with hdf5 libraries on eclipse CDT. When running a test C++ program, I got prompt information as below:
/home/lsl/Documents/CODE/eclipse-workspace/ReadWriteHDF5/Debug/ReadWriteHDF5:
error while loading shared libraries: libhdf5.so.103: cannot open
shared object file: No such file or directory.
libhdf5.so is confirmed to exist in /usr/local/lib/hdf5-1.10.4/lib and /usr/local/lib/hdf5-1.10.4/lib is within LD_LIBRARY_PATH. Do you have any indications?
Thanks very much!
It looks like Linux is your main operating system. See what happens when you type
sudo apt install libhdf5-dev
since it might supplant the package you're looking for. It worked for me.
I come across similar issue while compiling C++ code that uses Armadillo. Since I have anaconda installed, I find the libhdf5.so.103 file located at ~/anaconda3/lib. After I add the path to LD_LIBRARY_PATH, the error disappears.
I came across exactly the same problem today (perhaps the only difference is that it complaint libhdf5.so.200 was missing). What I eventually found out is that the system (Ubuntu 20.04) already shipped with libhdf5-dev at version 1.10.4, and this conflicted somehow with my installed version 1.12.2. My build command line is as below:
clang++ <...> -L/my/custom/path/to/hdf5-1.12.2/hdf5/lib <...>
Since the system hdf5 is in standard location, the linker finds simultaneously two versions, causing problem.
My solution is:
sudo apt purge libhdf5-dev
Hope it helps.
I have installed the latest version of Eclipse on my Windows 7 64-bit machine and the mingw compiler. In setting up a Hello World project, all goes well until I am asked for the Cross Settings what the Prefix is and the Path. The Path is obvious, it's the path to the compiler. However, I haven't the slightest idea what the Prefix is and Googling for much of the day hasn't enlightened me other than finding that a lot of other people have asked the question. Unfortunately the answers I've found appear to be for specific hardware. All I want to do is to produce an executable that will run on a Windows 32 bit or 64 bit machine.
So, what is the Prefix and how do I find what it should be?
What is probably happening here is that CDT is not locating your MingW or GCC installations.
simple - but unlikely reason - covering bases
There can be many reasons, from the simple - but unlikely at this point:
You don't have mingw installed
You don't have GCC installed
This can be tested easily by starting a shell and running gcc --version.
CDT heuristic not working
To more complicated reasons relating to your installation not being detected because the heuristic in CDT did not work on your machine. To find the correct settings, CDT will do:
Check $MINGW_HOME/bin for existence
Check <Eclipse install location>/mingw/bin for existence
Look for mingw32-gcc.exe or x86_64-w64-mingw32-gcc.exe on the PATH
Check C:\MinGW for existence
If CDT cannot find any of the above, you may lead to the situation you are in.
So, how to fix it!
Option 1
Start Eclipse from within a mingw set up shell. i.e. the one you can successfully run gcc --version from. That way Eclipse will inherit an environment that can launch GCC successfully.
Option 2
Set your environment up so that MINGW_HOME is properly defined. You can do this at the system level or within the build settings in Eclipse CDT. For example, on my machine in the build settings for the project (Right-click on the project, choose Properties, then choose C/C++ -> Environment) I have set:
MINGW_HOME to C:\MinGW
MSYS_HOME to C:\MinGW\msys\1.0
PATH to ${MINGW_HOME}\bin;${MSYS_HOME}\bin;<my normal path>
and this allows Eclipse to launch gcc as part of the build process.
NOTE The above setting were done automatically on my machine because mingw was correctly located by the heuristic.
Here is a screenshot of the build settings if it helps:
Prefix: Under the hood
To try and answer part of your original question about what Prefix is, I provide the below information. It is unlikely to be particularly helpf
Prefix, in GCC parlance, refers to the directory under which all the related GCC files are placed. With different prefixes you can have multiple GCC installed on your machine.
From the GCC FAQ:
It may be desirable to install multiple versions of the compiler on
the same system. This can be done by using different prefix paths at
configure time and a few symlinks.
The concept comes from autotools in general. Autotools is the standard GNU make system (where you do ./configure && make - simplified). The prefix is the command line option to the configure stage (--prefix) to specify where to install the tool to. GCC above uses the --prefix to allow multiple GCCs on your system.
If you really want to know more about this, read the autobook. The section on configuring covers --prefix:
‘--prefix=prefix’
The –prefix option is one of the most frequently
used. If generated ‘Makefile’s choose to observe the argument you pass
with this option, it is possible to entirely relocate the
architecture-independent portion of a package when it is installed.
For example, when installing a package like Emacs, the following
command line will cause the Emacs Lisp files to be installed in
‘/opt/gnu/share’:
$ ./configure --prefix=/opt/gnu
It is important to stress that this behavior is dependent on the generated files making use of this
information. For developers writing these files, Automake simplifies
this process a great deal. Automake is introduced in Introducing GNU
Automake.
Additionally, Mingw takes advantage of all this prefix options. Read more about that on mingw's site. But the short of it is that the main prefix for mingw is /mingw.
I'm having trouble cross compiling PostgreSQL for my TI Sitara AM335x EVM SK. My host system is an i386 machine running Ubuntu 12.04.
My application is written in C++ using Qt. When I try and compile, I get the error that libpq.so is incompatible. I believe this is because the cross compiler is trying to use the host libpq.so instead of one for the target system (which as I have found out, doesn't exist).
I've downloaded the source for PostgreSQL with the intention of cross compiling that in order to give me the libpq.so library that will be compatible with my target system, however there is virtually no information on how to do this.
I have tried using the CC argument with the configure file to change my compiler to the following: CC=/home/tim/ti-sdk-am335x-evm-06.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/arm-linux-gnueabihf-gcc but the configure script gives me this error: configure: error: cannot run C compiled programs. If you meant to cross compile, use --host.
The configure file makes a small reference to the --host option, but the only information in the file that I could find is in reference to mingw and windows, which isn't what I want.
I've done some quick searching through the configure file, and it references the --host option, but with no explanation of what is a valid host. I'm assuming that with --host option there will be an associated --target.
What arguments can I give the configure script so that it will cross compile with the correct compiler to generate a library that my target device can use? Are there any resources out there that I haven't found in regards to how the --host/--target works or how to use them?
OK, so after fiddling around for a little while, I think I was actually able to cross compile PostgreSQL and answer my own question.
Before I went any further, I had realized I had forgotten to add the path to my cross compiler to the PATH environment variable. I used the command export PATH=/path/to/cross/compiler:$PATH to insert the compiler path to the PATH environment variable.
Next, I did some experimenting with the --host option. To start off with I tried using ./configure --host=arm-linux-gnueabihf and running the configure script. The configure script seemed to accept this as the host argument. I then went to the next step of running the makefile. Running this makefile resulted in errors being generated. The errors were selected processor does not support Thumb mode. I did a quick search to see what information I could find about this error and came to this webpage: http://www.postgresql.org/message-id/E1Ra1sk-0000Pq-EL#wrigleys.postgresql.org.
This webpage gave me a bit more information since it seemed like the person was trying to do something very similar to me. One of the responders to the post mentioned that --disable-spinlocks is intended for processors that aren't supported by default by PostgreSQL. I emulated the arguments that were used in the website listed above and used the command: ./configure --host=arm-linux CC=arm-linux-gnueabihf-gcc AR=arm-linux-gnueabihf-ar CPP=arm-linux-gnueabihf-cpp --without-readline --without-zlib --disable-spinlocks to generate my makefile. This makefile actually generated all of the files, including the libpq.so library file I was needing.
Hope this helps somebody else in the future!
I installed cygwin (the latest 1.7.xx?), and then installed eclipse cdt (Juno).
When I tried to build a hello world project, despite eclipse identifying that cygwin was installed, it didn't work.
So I manually added c:\cygwin\bin to the path, which found all the executables in cygwin, including g++, make ld, etc.
Now, eclipse can build the project, but when debugging, gdb starts up and can't find the source code. It claims that it can't find:
/cygdrive/c/users/me/workspace/test1/test1.cc
.
even though that's exactly where it is. It's as though cygwin's directory system doesn't work.
I can manually load the source from:
c:\users\me\workspace\test1\test1.cc
and the debugger works, but the next time I start a new project, I have to do it again.
How do you instruct the eclipse/cygwin combo to correctly find source code?
Alternatively, is Mingw any easier? I have experienced similar problems with eclipse seeing that mingw is there, but build failing because it doesn't find the executable.
Here is how I made it work.
I goto Window ==> Preferences ==> C/C++ ==> Debug ==> Source Lookup Path
I Add a Path Mapping: Project Source
On the left side I put the path that Cygwin expects, i.e. \home\MyName\projects and on the right side I put the Windows path, i.e. C:\cygwin\home\MyName\projects
Then when I debug it finds the source file fine.
Go to Windows->Preference->C/C++ -> Debug -> Source Lookup Path. Add following 'Path mapping'.
\cygdrive\c -> c:\
Although Above are given good answers but still it might not solve the problem sometimes phew!!!!
Suppose you install Cygwin in C: but your eclipse workspace is in D: then there is a problem in your mounting
all you should do is, open the cygwing shell & type "mount" to get the following :
Ritvika#Ashutosh ~
$ ls
Ritvika#Ashutosh ~
$ mount
C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin64 on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
Ritvika#Ashutosh ~
$
here my Projects are all under D:\ECWorkSpace, so my mapping needs to be present
in Eclipse as:
/cygdrive/d d:/
Hence, now Armed with this knowledge do what PathM says
1. goto Window ==> Preferences ==> C/C++ ==> Debug ==> Source Lookup Path
2. Add a Path Mapping: Project Source
3. On the left side put "cygdrive\d", & on the right put : "D:\"
This should work. ( It did for me :) )
You can Check this FAQ as well : https://wiki.eclipse.org/CDT/User/FAQ#I.27m_using_cygwin_and_when_launching_the_debugger.2C_it_complains_that_it_can.27t_find_the_source_file
I use MinGW + CDT, and it is giving me great satisfaction. I installed it many times and never had any disagreement. No much to configure than what you did with cygwin. Download the Eclipse for C/C++ developers (probably what you did) to get CDT (MinGW Tool Chain -> gdb + gcc) directly operational. Set your \\MinGW\bin\ directory into your PATH and you should be good to go...
Note : Like Cygwin, MinGW provides a Linux-like Shell.
For MinGW-64, ready-made builds are a little bit more difficult to locate. See here.
Look at set-up of "Common Source Lookup Path" here: http://wyding.blogspot.dk/2009/04/setup-cygwin-toolchain-in-eclipse-cdt.html
I replaced gdb with msys gdb. For example:
Current configuration:
... Application Configuration .. Debug .. Debug
GDB Debugger gdb
to
GDB Debugger path to msys gdb (like for example c:\msys\bin\gdb.exe
I know no Perl, so please be patient!
This is a bit from the script, that generates the error:
if (-x '/usr/bin/gcc') {
$gcc = Fink::Services::enforce_gcc(<<GCC_MSG);
Under CURRENT_SYSTEM, Fink must be bootstrapped or updated with gcc
EXPECTED_GCC, however, you currently have gcc INSTALLED_GCC selected.
This typically is due to alteration of symlinks which were
installed by Xcode. To correct this problem, you will need
to restore the compiler symlinks to the configuration that
Apple provides.
GCC_MSG
$gcc = "-gcc" . $gcc;
}
This script installs fink package manager on Macs. (I'm not a Mac user, trying to help out my friend to install a program that is originally a GNU program and needs to be compiled from sources).
The install script complains about the version of GCC being not what it expects. I suspect that this is the place that fails, but don't quite understand what is it doing.
I've tried creating a symlink to the installed GCC, which is version 4.2.1, while fink wants version 4.2.
This message is displayed if I put a symlink to GCC into /usr/bin. Otherwise it identifies the version of GCC properly and refuses to install.
I thought that -x switch is similar to Bash and means that it is checking that the file is an executable, but I'm not sure what exactly does it do in Perl and would it treat a link to an executable as executable?
Thanks!
it test is the file has the executable bit set.
in your case: chmod -x /usr/bin/gcc will cause your if block to no execute.
chmod +x /usr/bin/gcc will casue your if block to get execute.
Perl's file test operators (you can see the documentation using the command: perldoc -f -x) usually do follow symlinks, with the exceptions of -l and lstat(). If you specifically want to test the link rather than the target, you can first do one of those, and then test -x _; _ as an argument makes it reuse the last stat results.
-X File is executable by real uid/gid