USB GCC Development Environment with Libraries - gcc

I'm trying to get something of an environment on a usb stick to develop C++ code in. I plan to use other computers, most of the time linux, to work on this from a command line using g++ and make.
The problem is I need to use some libraries, like Lua and OpenGL, which the computers don't have. I cannot add them to the normal directories, I do not have root on these computers. Most of the solutions I've found involve putting things in /usr/lib/ and the like, but I cannot do that. I've also attempted adding options like '-L/media//lib', which is where they are kept, and it didn't work. When compiling, I get the same errors I got when first switching to an OS with the libraries not installed.
Is there somewhere on the computer outside of /usr/ I can put them, or a way to make gcc 'see' them?

You need more than the libraries to be able to compile code utilizing those libraries. (I'm assuming Linux here, things might be slightly different on e.g. OSX,BSDs,Cygwin,Mingw..)
Libraries
For development you need these 3 things when your code uses a library:
The library header files, .h files
The library development files, libXXX.so or libXXX.a typically
The library runtime files , libXXX.so.Y where Y is a version number. These are not needed if you statically link in the library.
You seem to be missing the header files (?) Add them to your usb stick, say under /media/include
Development
Use (e.g.) the compiler flag -I/media/include when compiling source code to refer to a non-standard location of header files.
Use the compiler/linker flag -L/media/lib to refer to non-standard location of libraries.
You might be missing the first step.
Running
For dynamically linked libraries, the system will load those only from default locations, typically /lib/ , /usr/lib/
Learn the ldd tool to help debug this step.
You need to tell the system where to load additional libraries when you're running a program, here's 3 alternatives:
Systemwide: Edit /etc/ld.so.conf and add /media/libs there. Run ldconfig -a afterwards.
Local, to the current shell only. set the LD_LIBRARY_PATH environment variable to refer to /media/lib, run export LD_LIBRARY_PATH=/media/lib
Executable: Hardcode the non-standard library path in the executable. You add this to the linking step when creating your executable: -Wl,-rpath,/media/lib
Etc.
There could be other reasons things are not working out, if so,
show us the output of ls -l /media/libs , and where you put the library header files, the command line you use to compile/link, and the exact errors you get.
Missing the headers and/or development libraries (for dynamic libraries there is usually a symlink from a libXXX.so to a libXXX.so.Y , the linker needs the libXXX.so , it will not look directly at libXXX.so.Y)
using libraries not compatible with your current OS/architecture. (libraries compiled on one linux distro is often not compatible with another distro, or even another minor version of the same distro)
using an usb stick with a FAT32 filesystem, you'll get in trouble with symlinks..

Related

How to run a C program in android-x86 terminal?

I have to C program which is compiled using gcc in ubuntu. I want to run that executable in android terminal. When i run it is showing either "file or directory is not found" or "not executable:ELF32".
I want to run the code in android terminal. Is there any way or flags in gcc or using any other compiler so that i can run my code in the android terminal.?
Android does not use the same system libraries as Ubuntu, so they will not be found.
There are two solutions:
Copy the libraries you need.
If you can place them in the same filesystem locations they have in Ubuntu then great, otherwise you'll need to run the ld-linux.so manually and tell it where to find the libraries. Or, you could relink the program such that it expects to find the dynamic linker and libraries in a non-standard place. You might also use a chroot, but that requires root, and you'd need to find a chroot binary that works.
Use a static link.
This usually just means passing -static to GCC. You get a much larger binary that should be entirely self-contained, with no dependencies. It requires that static versions of all your libraries are available on your build system. Also, some features (such as DNS lookup) always expect a shared library, so they won't work this way.
Even then, you should expect some Linux features to not work. Basically, anything that requires hardware features or configuration files in /etc are going to need a lot of effort. There are various projects that have done this already (search "linux chroot android").
I'm not sure what the "not executable:ELF32" message means, but you should check whether you're building 32 or 64-bit executables, and which the Android binaries are using (file <whatever> should tell you).

How to set external clang directory as default gcc in macports for subsequent port installations?

I downloaded the clang compiler directly from the prebuilt binary tar provided on the llvm website here. The tar file contains a standard directory hierarchy with bin, include, lib etc. Now I want to configure macports to use this compiler in such a way that when a subsequent port requires clang then this compiler's binary is used. Note that I do not want macports to download and install a separate copy of clang. Is it possible to do so?
DETAILS: The reason why I want to keep the clang installation in a separate place is because I often use scientific code, or other code, like chromium, and I use anaconda. I also have xcode installed and that provides its own version of compilers. Adding macports' compilers to the system makes my system almost unmanageable because it is often very difficult to ensure that the right runtime library and compilation time library are being used.
MacPorts does not support this, and there is also no unsupported way to get this done that I am aware of.
However, C++ software installed through MacPorts should always end up using the libc++ runtime (if you're on a system where it is the default). MacPorts is aware of the C++ runtime its ports use and tries to make sure all its ports use the runtime set as the cxx_stdlib in macports.conf (which defaults to your system's default).

OSX Xcode - Packaging dependencies libmysqlclient.18.dylib

This may well have been asked before I just couldn't figure out the right term to search.
I'm writing a client-server application to run on an OSX desktop which will talk to a MySQL server on the local network. It seems long-winded to implement a web-services API when basically a bunch of SQL statements will be perfect internally.
I've wrestled with the install procedure for MySQL server on my development machine, ad had to resort to symlinking libmysqlclient.18.dylib into /usr/lib even though i'd put the include path in header search paths.
What I need to know is how do I create a .app file I can send to other machines that will have access to the libmysqlclient.18.dylib file?
I'm used to Windows having installers to do this and a bit new to OSX programming although i've been doing Obj-c for iDevices for 2 years.
Is there a setting which allows the library to be copied into the .app file or do I need to install the mysql connector on each machine - if so, how do I get around the symlink issue, ideally I need it to work from the stock folders.
If this has been answered somewhere else, please point me in the right direction.
At build time the static linker on OS X, ld, writes the shared library identifier of each library that your application links against in to the application binary. At run time the dynamic linker, dyld, attempts to load each shared library from the paths specified in the application binary. You can see this information using otool -L YourApp.app/Contents/MacOS/YourApp.
The fact you needed to symlink libmysqlclient.18.dylib in to /usr/lib suggests that the shared library identifier of libmysqlclient.18.dylib is something like /usr/lib/libmysqlclient.18.dylib. To include the library in your .app bundle in a way that your application will use it rather than looking in /usr/lib you need to:
Change the shared library identifier of libmysqlclient.18.dylib so that dyld will look for the binary relative to your application binary. This is typically done by running install_name_tool -id #executable_path/../Frameworks/libmysqlclient.18.dylib libmysqlclient.18.dylib.
Copy the modified libmysqlclient.18.dylib in to the Frameworks subdirectroy in your application bundle. This is typically done using a Copy Files build phase in your Xcode project.
You should then be able to verify that the install name written in to your application binary is #executable_path/../Frameworks/libmysqlclient.18.dylib rather than /usr/lib/libmysqlclient.18.dylib (using otool -L YourApp.app/Contents/MacOS/YourApp again). If the install name isn't correct then you'll need to ensure that your linker search path is set up to find your modified version of libmysqlclient.18.dylib ahead of any other versions you may have.

Should I care that the symbol version dump is missing? How do I get one?

I am trying to compile a driver that we have from source and I am working through the issues with a new target environment. One of the slightly disturbing things I see is the following warning:
WARNING: Symbol version dump /usr/src/linux-2.6.38/Module.symvers
is missing; modules will have no dependencies and modversions.
I spent a fair amount of time looking on the web and this is shown in output frequently when other questions are asked, but I didn't see any commentary about whether or not this is an issue.
In any case, how would I tell linux/ubuntu to generate Module.symvers?
Module.symvers is generated when the kernel itself is compiled and ought to be provided to the user as part of the kernel build environment package, however that may look on Ubuntu (possibly broken there?) Fedora and openSUSE for example ship one or more “kernel-devel” (and/or similarly-named) packages that ship this build environment and make the file reachable through /lib/modules/<version>/build/Module.symvers. When using a self-compiled kernel, substitue /lib/modules/version/build for the appropriate path to the build directory (where all the .o files are).

Boost 1.48.0 on Fedora Core 16

I'm trying to install ONLY the Boost Libraries 1.48.0 that are 100% complete from FC17 on an FC16 system. I have scoured the net but can't figure out how to do it. I have attempted to upgrade to rawhide but there are too many broken dependencies. I was hoping to just be able to upgrade that one package, as hopefully I don't believe I have too many programs installed that depend on Boost libraries (just the ones I'm coding).
I need to use the new features in 1.48.0. If I can't install them via an RPM, can I compile them as a normal user, store them in ~/lib and link against them?
I'm on FC16 x86_64.
Yes you can. You just need to export several shell environment variables in your shell profile to tell the compiler where to find your new boost header files and shared object files.
# For C and C++ header files search path
export C_INCLUDE_PATH=$your_new_boost_include_dir:$C_INCLUDE_PATH
export CPLUS_INCLUDE_PATH=$your_new_boost_include_dir:$CPLUS_INCLUDE_PATH
# link path
export LIBRARY_PATH=$your_new_boost_lib_dir:$LIBRARY_PATH
Usually you'll also need to do the following so that the compiled executables can be linked to the right version of shared object files at run time:
# run-time
export LD_LIBRARY_PATH=$your_new_boost_lib_dir:$LD_LIBRARY_PATH

Resources