Skip to main content

[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




Back to the top