[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Finding stdc++ library path automatically
|
Am 06.05.2011 09:26, schrieb Petri Tuononen:
Thanks for giving me something to think about.
On 05/06/2011 04:45 AM, kesselhaus wrote:
Even on windows it is tricky.
a) There might be no cygwin or mingw
This is not problem because then the LLVM plug-in I am developing is
simply not supported, because it is dependent on MinGW or Cygwin on
Windows.
For example, the llvm-gcc frontend brings all the headers and libs. No
MinGW needed.
b) There might be both
I was thinking that stdc++ library paths would be located for cygwin
and mingw (if they're installed) and then 'the right path' is passed
to linker according to the used toolchain configuration.
c) MinGW might not be in C:\MinGW but somewhere else
Luckily MinGW environment supplier class can handle this.
Just as an example. The MinGW support in CDT usually looks only for
C:\MinGW. That is the problem for CDT to show MinGW compiler as "Not
supported". Unless unchecks the "Show only supported Toolchains", the
MinGW compiler can not be selected in the project wizard.
d) There might be a different solution like the distribution from
equation.com
I am not able to see how this would affect getting MinGW or Cygwin path.
This distribution does install whereever you want. It contains gcc, g++,
gfortan, gdb and make, but no Msys shell is included with that.
So, the makefiles here should consider just the default windows cmd.exe
as environment.
e) There might not be a path entry in environment variables (e.g.
multiple installations, and/or gcc might be added to PATH by script
or hand)
Good point. However I fail to see why someone would like to use gcc in
alternative path because this might be tricky especially for MinGW. In
any case user is always able to add his/her own library paths via
preference page. The feature I am planning would locate the stdc++ lib
path from default locations (at least for now).
As I said, e.g. multiple versions of gcc (4.5, 4.6, 3.x), or you might
not like to install your toolchains on drive C: but e.g. on D:.
There are people with restricted access, which install into some
location they have access to.
Or, some people like to have their toolchains local in a projects
sandbox (which means, you check out a project from version control and
this includes the toolchains in some folder below that sandbox base.
f) There might be llvm-gcc with the libs
Does not consider MinGW but in case of Cygwin we could check both
locations and prefer libs within llvm-gcc (if llvm-gcc toolchain used).
There is a binary distribution of llvm-gcc frontend which includes all
libs and headers.
The same might apply for clang in the near future. At least the #llvm
channel agreed to my suggestion that it would be an good idea.
Up til now, clang was not even provided as binaries for windows. Which
was as I think, a major showstopper for interested people.
g) There might be a clang build which includes mingw headers as
llvm-gcc (asked about such distribution pn #llvm)
The default case is that user is supposed to use LLVM, Clang and
LLVM-GCC binaries for MinGW (from LLVM 2.9 onwards). Using MinGW is
the most preferred method anyway if user does not want to build LLVM
from sources which takes very long and consumes a lot of hard drive
space.
As I said, the clang binaries for windows came on my request on #llvm,
and I also asked for the inclusion of libs and headers.
The former way was to install a mingw on C:\MinGW, which is something I
regret for some reasons.
The clang would use the hardcoded paths formerly, but that might change
soon.
Indeed it is becoming clear that there are no simple and 100% working
solution for this but I will implement this feature as far as I can.
As for now the easiest way to get stdc++ lib path for Linux and Mac OS
systems seems to be calling a shell script. Not sure if the file
permissions (execute rights) becomes a problem. Of course one could
use Java for this as well but I am worried about the time it takes to
find the path, because it should be found almost instantly.
I would go for a simpler approach.
Usually, a compiler distribution has a given layout, which usually
means, a base directory where the compiler actually is.
The binaries are usually in a bin folder within that base folder, the
same applies to the libs and the docs.
So, check:
1) Where is the compiler installed e.g. X:\dira\dirb\clang\bin
2) Within the compilers directory and/or the path above
(X:\dira\dirb\clang\ ), check for includes/libs
3) Then check for some other directories if you really need to.
Provide the possibility to set them per hand (BASE, BIN, INCLUDES, LIBS
etc.pp.)
Petri
Am 04.05.2011 10:56, schrieb Petri Tuononen:
Hello!
Could someone provide any clues how to find stdc++ library path (not
dependent on OS) programmatically using Eclipse CDT API. I try to
add it to projects's includes.
I am developing LLVM plug-in for CDT and many people have asked the
feature to automatically find stdc++ library path. Currently the
clang++ toolchain is able to find same includes than e.g. Linux GCC
toolchain from org.eclipse.cdt.managedbuilder.gnu.ui plug-in. I have
defined default value -lstdc++ to C++ linker. In Windows I can
probably get stdc++ path from Cygwin/MinGW environment variable
suppliers after getting their installation path and appending
applicable subdir. However in Linux getting stdc++ lib path seems to
be trickier. In Ubuntu (depending on gcc version)
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/<version> but there's
quite many distributions with different filesystem hierarchies. It
came to my mind that using a script 'locate stdc++' could be
(unpractical) option but how to call such a script from Eclipse? Any
suggestions for practical solutions?
BR
Petri
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev