Mac OS X 10.5.8 linker problems and some questions about current status

[Smirftsch]

I asked already a few questions in the general forums about compiling CodeBlocks from SVN for MacOS. After some initial trouble I found out that it is running ok when starting it as administrator, why it is that way I really don't know.
But thats not the main problem.
If I want to link a project which I have working fine in Win and Lin in OS X. One library out of a project in the workspace I wanted to link against an other one, buld before.
Lets name those projects a.dylib, b.dylib and executable.bin
First I build a then b which needs to be linked against a and then the executable against a and b.
I'm using an own build gcc3.4.6 which is installed in /opt for that purpose while it seems to behave the same way if I'm using the included 4.01.
 
It links fine if I set in the linker settings in link library for b
../../OutputDir/a.dylib

and for the executable
../../OutputDir/a.dylib
../../OutputDir/b.dylib
Maybe I got something wrong or don't understand it yet in OS X, but for this it links fine using g++, but when running it, I need to set DYLD_LIBRARY_PATH to ./ otherwise it looks for them in ../../OutputDir and doesnt start.

It also works if I don't use the specific output dir and place the libs to link again in the same path as the src, but still I need to link with ./a.dylib

Not very happy about this behavior I tried to add ../../OutputDir to linker search path, but whatever I tried, it seemed to ignore it, until I noticed, that if I add the library into the linker settings as "a" or "a.dylib" instead of "./a.dylib" it tries to use suddenly libtool instead of g++, why is that?

Also noticed that I can't set -Wl,-stack_size -Wl,1000000 it also tries to run it with libtool and fails with some obscure error:
/usr/bin/libtool: unknown option character `t' in: -stack_size

which is at least currently more of a problem for me since I can work around pretty easily around the first issue with the DYLD_LIBRARY_PATH.

I hope this is information enough, where can I adjust this behavior to prevent it from trying to use libtool?


Secondly, OS X version of Codeblocks seems to be kinda buggy yet, if it comes to some settings, the requirement to need to be administrator, some windows seem to jump away if I want to select something and the window size of some preferences windows are incredibly large which causes weird problems because usually I'm working from my notebook which doesn't allow me a screensize of bigger than 1280x800. The windows can't even be resized sometimes and some buttons like the advanced button in compiler options I can't select because they are just of the screen.
Is it assumed that everyone is using a >1600x1050 screen or a bug?
Also the handling of project settings is kinda messy, I need to activate a project first before I can change its build settings with right mouse, otherwise the settings set....what? - no idea, at least not the build options for the project I click on.
Almost everything above works perfectly fine in my Linux version- so my question is, are there intentional changes especially for OS X to adjust to its different "usual behavior for Mac's", or a bug?
I personally would prefer one handling for all platforms, because the way its done in Linux is way more logical and clear and its kinda annoying to change the way how to work everytime I switch from Lin to OS X.

[afb]

I asked already a few questions in the general forums about compiling CodeBlocks from SVN for MacOS. After some initial trouble I found out that it is running ok when starting it as administrator, why it is that way I really don't know.

Secondly, OS X version of Codeblocks seems to be kinda buggy yet, if it comes to some settings, the requirement to need to be administrator,

There is no such requirement. Running as a user should be perfectly OK...

some windows seem to jump away if I want to select something and the window size of some preferences windows are incredibly large which causes weird problems because usually I'm working from my notebook which doesn't allow me a screensize of bigger than 1280x800. The windows can't even be resized sometimes and some buttons like the advanced button in compiler options I can't select because they are just of the screen.
Is it assumed that everyone is using a >1600x1050 screen or a bug?
Also the handling of project settings is kinda messy, I need to activate a project first before I can change its build settings with right mouse, otherwise the settings set....what? - no idea, at least not the build options for the project I click on.
Almost everything above works perfectly fine in my Linux version- so my question is, are there intentional changes especially for OS X to adjust to its different "usual behavior for Mac's", or a bug?

Probably bugs. And lack of testers/users. But probably bugs (C::B or wxMac).

[afb]

Also, it is possible to run the wxGTK (X11) version of Code::Blocks on Mac OS X if the GUI problems gets too annoying. Like a last resort or something, but if you just want it working more similar to what it does on Linux ? (you'd still have to fight libtool and friends, but the windows should be similar)

[Smirftsch]

All I see now that it doesn't save correctly the window settings or the compiler settings like my additional gcc in opt if I don't start it as administrator. Also it sometimes doesnt even start up at all if running as user.
The menu is OS X like and that's ok, but f.e. the project build settings are entirely different in OS X. In Linux I can switch for every compiler and mode, but in OS X I have to activate the project in its build mode as release or debug and then set the build settings f.e., that's what I meant.

Seems like I almost volunteer here now for OS X testing eh?

But thx for the hint with wxGTK, going to try it when I find some time to rebuild CodeBlocks

[oBFusCATed]

If you run it as admin, where does it save its settings?
On linux it is ~/.codeblocks, or OSX should be something similar.
There is a tool DTrace that should be able to help you, to find what C::B is trying to do

[afb]

On linux it is ~/.codeblocks, or OSX should be something similar.

It is ~/Library/Application\ Support/CodeBlocks, as per wxStandardPaths (i.e. when using wxMac)

[afb]

But thx for the hint with wxGTK, going to try it when I find some time to rebuild CodeBlocks

Code: macports.org

sudo port install codeblocks-devel +x11

[Smirftsch]

well, that should be /private/var/root/Library/codeblocks/Application Support/codeblocks

oh...thx afb

[Smirftsch]

after some more digging I found out that my problem is maybe just that I need to invoke glibtool instead of libtool.
LIBTOOL=glibtool is to be exported, so at least I read. Where do I set this in CodeBlocks?