Cross-compile with relative pathnames - for binary portability/embeddability? (GCC)

Say I am creating an application bundle with some scripts, maybe a daemon, or even a helper binary... When compiling such a binary.. is it feasible to ./configure/make it with only relative paths? For example, a more conscientious Makefile will include for provisions such as...

--bindir=DIR           user executables [EPREFIX/bin]
--sbindir=DIR          system admin executables [EPREFIX/sbin]
--libexecdir=DIR       program executables [EPREFIX/libexec]
--sysconfdir=DIR       read-only single-machine data [PREFIX/etc]
--sharedstatedir=DIR   modifiable architecture-independent data [PREFIX/com]
--localstatedir=DIR    modifiable single-machine data [PREFIX/var]
--libdir=DIR           object code libraries [EPREFIX/lib]
--includedir=DIR       C header files [PREFIX/include]
--oldincludedir=DIR    C header files for non-gcc [/usr/include]
--datarootdir=DIR      read-only arch.-independent data root [PREFIX/share]
--datadir=DIR          read-only architecture-independent data [DATAROOTDIR]
--infodir=DIR          info documentation [DATAROOTDIR/info]
--localedir=DIR        locale-dependent data [DATAROOTDIR/locale]
--mandir=DIR           man documentation [DATAROOTDIR/man]
--docdir=DIR           documentation root [DATAROOTDIR/doc/hiawatha]
--htmldir=DIR          html documentation [DOCDIR]
--dvidir=DIR           dvi documentation [DOCDIR]
--pdfdir=DIR           pdf documentation [DOCDIR]
--psdir=DIR            ps documentation [DOCDIR]

This is great, you can install everything to /opt/local instead of /usr/local. Maybe even go crazy, and rename the binaries via sed.. I get it..

But what remains unclear in my tiny brain, is if the ability to arbitrarily set paths in such a manner extends to the ability to map the directories relative to the executable, in a manner similar to...

--prefix=PREFIX    install architecture-independent files in PREFIX [/us开发者_如何学Cr/local]
--prefix=./        aka  [../relative/to/binary]     

So, for example, no matter where you launched the bin from, it would always know that it's .conf file was going to be up one folder, in the that relative ../etc folder, or possibly even right next to it, in the same directory, ./. Similarly, you could guarantee write access to log and pid files, etc, without wondering about your target's permissions/directory structure...

This would enable a completely portable /bin /etc /lib /var directory structure, within a PATH to which I can guarantee some semblance of predictability... but I don't think it just "works" like that.. And I am unsure if simply "linking statically" or otherwise ? truly creates binaries that are able to be moved to another system (albeit, for this scenario, to ones with the same support libs in the same places, so as not to muddle the issue) Is it possibly to cross-compile in this manner? And can you build for multiple architectures in the same build cycle? (For example i386 AND x86_64 at the same time)

Maybe I could just use a recommendation of a good GNU/GCC primer ( CC, CFLAGS, LDFLAGS, -l, , -I , and CPP 101, etc.) but that wasn't written for (and by) Math teachers - in the 70's?

In full generality, no, that won't work. There are things in /etc for example that are expected to be shared by the whole system and won't work correctly if you're trying to keep a private copy for one app.

With that said, your app probably isn't using every single shared resource on the system. Either using a local /bin and /sbin, or symlinking to the real ones from a relative path within your app's directory should be fine. /var seems less likely as something that your app needs to know about directly - anything stopping you from storing logs your own way, or using syslogd?