g++ (v 6.3.1) - or more exactly ld - seems unable to make use of library paths provided by -L when used as non-privileged user (e.g. non-sudo, default user).
Background is: I'm trying to compile a C++ program for 'real' 32bit architecture (i386 not i386-x86_64 where pointers are 32 bit and the real program is run on a 64 bit system) on a 64bit system (x86_64).
the '-m32' option works fine for compiling, I guess the paths are correct there. for linking therefore i need to supply -L/usr/lib32 to make g++ look in the real 32 libs first, as the others will not fit the architecture. the path supplied this way is only searched by g++ when sudo. when non-sudo the libs are not found because the path is not added to the search dirs of g++. i think this is a privileges based bug for solus, more likely than a bug in g++, as it would then occur in a lot of other cases. my case of developing 32bit in 64bit solus however is rather specific I guess...
I struggled with this for hours until I found the problem, so to help others I thought it a good idea to report this.

(or did I forget to join a special developer tools group? all the other dev tools work fine)
if you need more details please tell me, this is the first bug i report ever, so i am not used to it

forgot to supply info about how exactly to reproduce this:

1. use g++ with the -c option to compile some C++ fragments to object files, use -m32 option to set target 32 bit arch.
2. as default user: link the object files and stuff from the stdlib by running g++ with -o, and provide the libs path by "-L/usr/lib32"
3. g++ will report incompatible architectures as it only looks in x86_64 and i386-x86_64 in /lib
4. append "-print-search-dirs" to the g++ linking command to print the search dirs only (linking is not done in this case)
5. repeat the linking step as sudo, this time 32bit libs will be among the searched dirs and linking will succeed with a working executable