How do I find what the Eclipse Cross Settings Prefix should be? - eclipse

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.

Related

How do I specify a compiler in a different directory than MinGW in a NetBeans Toolchain module

I am attempting to make a simple ToolChain for the Borland 4.5 compiler with the Pharlap extender based on instructions at the Apache website: https://netbeans.apache.org/kb/docs/cnd/toolchain.html
I am basing the ToolChain on MinGW so that I can use those tools for make.
I cannot get the new toolset to find the Borland compilers the way MinGW is automatically discovered. If I use g++ as the compiler name, Netbeans finds that OK. The issue seems to be with the directory. I'm assuming an installation directory of C:\BC45\BIN and attempting to find BCC32.EXE in that directory.
When I run (clean, build, then run) the test installation of the netbeans module, I see my new toolchain in C/C++, but the field for the C++ compiler is always empty unless I specify a program in the c:\mingw\bin (base) directory.
I have tried variations on the following in my cpp xml file, making sure from time to time that it works just fine with g++ as the name:
<cpp>
<compiler name="bcc32.exe"/>
<recognizer pattern=".*[\\/]bc45.*[\\/]bin[\\/]?$"/>
I haven't found documents beyond the Apache website. I'm basing my guesses on what I have found in: %appdata%\NetBeans\12.4\config\CND\ToolChain\MinGW.xml
The XML above was OK as far as it goes. The example at apache.org only fills in the subclass of c++ (cpp). When I also subclassed the c, assembler, and linker, I ended up with the fields in the C++ options automatically populating as expected.
vcc4n (https://sourceforge.net/p/vcc4n/wiki/Home/) has a good example of implementing the four important classes for those build tools, but really just continuing the example to create and fill in the additional XML as specified in layer.xml is straightforward enough.

Swift toolchain location on Linux

I'm looking into running Swift on a Ubuntu 16.04 server. However I want to be certain about where I should install the toolchain.
From swift.org:
If you installed the Swift toolchain on Linux to a directory other than the system root, you will need to run the following command, using the actual path of your Swift installation...
Then from Kitura's Setting Up instructions:
After extracting the .tar.gz file, update your PATH environment variable so that it includes the extracted tools:
$ export PATH=<path to uncompressed tar contents>/usr/bin:$PATH
Where is the best place to install these type of things? In the past I would rely on apt-get or installation scripts provided by maintainers but this doesn't seem to be the case with Swift.
Are there any benefits or disadvantages to not installing it at the system root?
Note: This question borders on "best practices", which I believe is frowned upon here. I'm sorry about that; I've googled around and this seems to be something that people know implicitly. However, I don't yet and need some guidance
The versions of the software in your system root - in /usr/bin, /usr/share, /usr/lib, etc. - are carefully coordinated by the maintainers of your distribution to handle all reasonable dependencies. The maintainers also keep the software up-to-date with bug fixes.
When you need to install software that isn't supplied by your distribution, it's best to install it in a separate directory, such as /opt (in your case, one possibility is /opt/swift-3.1.1). This will avoid overwriting existing installed software (in your case, /usr/bin/lldb and /usr/lib/lldb) with something that's possibly incompatible with other software. And it will make it easy to uninstall (just rm -r /opt/swift-3.1.1 rather than having to get a list of files from the original tarball that are potentially strewn all over /usr).
There is some extra effort: you'll need to add /opt/swift-3.1.1/usr/bin to your PATH1. With some software, you'll need to add the directory containing dynamic library files to LD_LIBRARY_PATH. The software's installation instructions typically explains what you need to do.
[1]An alternative to changing PATH is to add a symlink to each new executable, in a directory that's already in your PATH. GNU Stow can help you do this.

Installing Perl and GCC on NFS

We have 15 Solaris-10 (Dinosaurs, I know) zones, all of which have a few NFS-mounted file systems. In fact, I have been installing my Perl scripts there so that I need only edit once and it is updated for all 15 zones. We have an opportunity to install Perl-5.20 in a separate directory tree from the Perl-5.8 environment the users are [in their view] locked into. Similarly, they see themselves as locked into gcc 3.3.2, terrified to budge. We have an opportunity to install the latest gcc (including g++, of course) in a similarly alternative directory tree. I guess the idea would be to install the new gcc, then use that to configure and compile Perl.
The problem: Configuring the new Perl and gcc installations in a different directory tree from the default is kinda error-prone. (There are likely another non-default options as well.) To do the same non-standard installations 15 times is SO inviting a screw-up!
My solution (maybe): Install the newer Perl & gcc in a directory on an NFS-mounted file system, like my utilities. Those in the know (the DBAs mainly) would put that directory earlier in $PATH than /usr/local/bin. Those not in the know - said terrified users - would remain blissfully unaware of the much better tools under their noses and never the twain shall meet to be blamed for messing up the environment of the other.
Is this a realistic solution? Are there library dependencies within Perl and gcc that would rule out an NFS installation? Has anyone done this before? (Actually, I think they did this at one place I worked but the always messed the code in the process.)
Thanks much for help here.
-- JS
I recently built gcc 4.9 from source and used it to build Perl 5.18.2 on Solaris 10 on an NFS share without any problems. Our stack of cpan modules installed without issue, including DBD::Oracle.

netbeans c++ deployment

I had developed a small program in netbeans using c++. I need to know how can i deploy/run the package on another linux system
Abdul Khaliq
I have seen your code, you probably missing XML files in the current folder... where the executable is located... paste then and then run as ./your-executable
I recommend that you use a makefile to recompile on your target machine which will ensure that your program is deployed properly.
You should use a makefile as suggested. I know that NetBeans can generate one, but it's been a while since I last did so. Maybe this can help: http://forums.netbeans.org/topic3071.html
Typically, once compiled, your executable will need several libraries. Chance is that those libraries will also be available on the target linux system.
Thus, you can simply copy your executable over to the other system. If you run ldd on your executable, you should see the list of libraries your executable is dynamically loading. Those libraries should be available on the target system as well.
In case your executable makes use of resources such as images and other binary files, you can use a resource system (e.g. Qt Resource System) and compile those binary files into your executable.
The easiest way to test is to do the copy, run
ldd yourExecutable
on the target system. It will tell you if you are missing any library. Install those libraries using the system package manager.
Of course, you also have the option to statically build all libraries into your executable. However, this is not recommended since it makes the executable too large and complicates matters.
What type of package is your netbeans compiler creating? deb,rpm? If you are moving the package to a different linux install you will need to use that distributions package type. Ubuntu - deb
Fedora/Redhat - rpm
etc...
I'm not sure how you change this in netbeans but I'm pretty sure it has the ability to. A google search could help you more.

Internal Builder: Cannot run program "g++": The system cannot find the file specified

****** Internal Builder is used for build ******
g++ -ot1.o ..\t1.cpp
Internal Builder: Cannot run program "g++": The system cannot find the file specified.
Build error occurred, build is stopped
I am new to eclipse, on windows XP, want to run c/c++ progms + linux build (cygwin is installed with needed packages)
Above said error is coming and builds fails! Please kindly suggest.
Edit: appends to path env variable as e:\cygwin\bin;
This is for ref:
How did you setup your Cygwin toolchain in your Eclipse CDT?
(from the Alex Wu's excellent blog post in Alex's Tech Blog)
1/ Install the Cygwin properly, you need following packages:
binutils
gcc
gcc-core
gcc-g++
gcc-mingw-core
gcc-mingw-g++
make
gdb (needed if you want to support debug in eclipse)
you can check your cygwin installation using the 'cygcheck -c' command
2/ Add %cygwin%\bin to your env PATH, then open the eclipse. you will find the cygwin tool chain will be shown when you open a new c/cpp project wizard.
3/ Configure the GDB.
Go to Windows->Preference->C/C++ -> Debug -> Common Source Lookup.
Add following 'Path mapping':
\cygdrive\c -> c:\
\cygdrive\d -> d:\
other drives if any .......
I just ran into the same error; it was my first time using eclipse with cygwin. I am fairly new to eclipse as well but I was impressed with how powerful it was. It is unfortunate that this question was asked almost a year ago. In the interim, the software may have changed so much that my advice below may be something of an anachronism as far as this question is concerned.
I am using Eclipse IDE for C/C++ Developers
Helios Service Release 2
version 1.3.2.20110218-0812
uname says that the Cygwin version is CYGWIN_NT-6.1-WOW64
After following the (often obsolete) advice of many web posts on this issue, two things finally seemed to make it work. My sysadmin, who alone has privileges to perform software installations, needed to increase my access privileges to the cygwin/bin folder, which now stands as Read and Execute. Second, in eclipse I changed the type of builder to External: File>Properties C/C++ Build, Builder type: External builder. Build now works, though not without throwing some warnings. I am still confused about many of the intricacies of the installation, and I'm not sure why switching to an external builder made such a difference.
I agree with #pajton one needs to correct Eclipse's expectation of the Cygwin binary path from c:\cygwin\usr\bin to c:\cygwin\bin as Cygwin authors changed to mounting /usr/bin off the latter.
I needed to change the Eclipse's addition of the Cygwin binary directory to PATH from c:\cygwin\usr\bin to c:\cygwin\bin in two configuration locations of my developer build Juno 20120322-1740:
Project Properties / C/C++ Build / Environment
Run / Run Configurations... / Environment
I also changed the path to a shell interpreter in the discovery option Compiler invocation command from sh to c:\cygwin\bin\dash.exe,
Project Properties / C/C++ Build / Discovery Options / Cygwin C Compiler
Project Properties / C/C++ Build / Discovery Options / Cygwin C++ Compiler
This allowed to automatically populate include directories and built-in macros in Project Properties / C/C++ General / Paths and Symbols.
Because only Cygwin-built programs such as bash.exe, dash.exe resolve Cygwin-style portable symbolic links, I changed compiler invocation commands from gcc to gcc-4 and from g++ to g++-4,
Project Properties / C/C++ Build / Settings / Tool Settings / Cygwin C++ Compiler
Project Properties / C/C++ Build / Settings / Tool Settings / Cygwin C Compiler
Project Properties / C/C++ Build / Settings / Tool Settings / Cygwin C++ Linker
Perhaps, this will be done automatically soon as I see a change in the git repository claiming to address the issue,
Bug 364733 - Internal Builder does not work with Cygwin toolchain
As I investigated my issue, I went to Help / Install New Software... / Juno / Programming Languages / C/C++ Development Tools.
As I tried to upgrade the selected piece I got an unclear message saying that the requested upgrade was required by other parts. When I pressed "Finish", I received a prompt to restart. I do not know if I upgraded my CDT with these actions.
If you want to catch access violations at run time, create an external tool entry in Run / External Tools... / Configure External Tools. Specify c:\cygwin\bin\bash.exe as the program, ${workspace_loc:/PROJECT_NAME/CONFIG_NAME} such as ${workspace_loc:/test/Release} as the working directory and the command option followed by the program name such as -c "./test.exe" in the arguments. I found that c:\cygwin\bin\dash.exe does not route the stack trace produced by the Cygwin DLL to the stderr caught by Eclipse.
Another way to fix this is to go to
project properties / c/c++ build / settings / tool settings / cygwin C compiler
and change the command to
sh -c 'whatever was already there'
This will use sh to invoke the command, and thus it will resolve cygwin links. You will also have to do this for the assembler and linker. Of course you also have to make sure your path points to c:\cygwin\bin before starting eclipse.