How to get the usual menu items in the first menu

[Clemens]

Hi!

Another question.  On OS X, the second menu (next to the Apple menu) always has the name of the program and contains items such as "About", "Services", "Hide" etc., "Quit".

When I add a TMainMenu, the name of the first menu is overwritten by the program name (good), but I don't get the usual menu items.  How can I get the "Hide" etc. items?

Cheers,
Clemens

[Phil]

https://dl.dropboxusercontent.com/u/28343282/MacXPlatform/MacXPlatform_Part8.html

[Clemens]

Great, thanks!    Looks very useful, I am working through it.

By the way, how can I implement "Hide" and "Hide others"?  Is there a library function to call?

Cheers,
Clemens

[Phil]

The app menu's Hide AppName and Hide Others should already be present. See Lazarus IDE.

[Clemens]

I see.  I am using Cocoa, probably that's why I don't have the "Hide *" items.

Yes, in Lazarus the app menu looks very OS X like.

[Phil]

Lazarus uses the Carbon widgetset. If you're using the Cocoa widgetset, the last time I checked there were quite a few things that did not work there, this is probably just one more.

[Clemens]

Ok.  I may have to go with the Cocoa widget set because of a 64bit library I may have to use.

I guess the best way forward is to file bug reports for the Cocoa widget set.

[Phil]

Yes, it's worth at least logging a bug report. Things posted here will not get attended to.

Note that 32-bit libraries work fine on OS X too. You can easily create "fat" .dylib files containing both 32- and 64-bit libraries. OS X system libs are all like this, as are most commercial libs.

-Phil

[Clemens]

Ok.  I'll try to file bug reports when I have time.  It would be great to have full Cocoa support.

Thanks for your hint about the library.  I may well have been doing something wrong.  I built the stock HDF5 library and got a libhdf5.a, which I can only link with the 64bit FPC, not with the 32bit FPC.  This is what I get when I use the 32bit compiler:

Code: Pascal  [Select][+][-]

1. ld: warning: ignoring file libhdf5.a, file was built for archive which is not the architecture being linked (i386): libhdf5.a
2. Undefined symbols for architecture i386:
3.   "_H5close", referenced from:
4.       _FINALIZE$_$HDF5 in hdf5.o
5.   "_H5garbage_collect", referenced from:
6.       _PASCALMAIN in Reconstructor.o
7.   "_H5open", referenced from:
8.       _INIT$_$HDF5 in hdf5.o
9. ld: symbol(s) not found for architecture i386
10. An error occurred while linking

[Phil]

Right, you built libhdf5.a for 64-bit only. Try building it for both if that's an option (don't know what hdf5 is).

For any .o, .a, .dylib, etc. use the file command to see what archs it contains.

[Clemens]

They are indeed 64bit:

Code: Pascal  [Select][+][-]

1. libhdf5.100.dylib: Mach-O 64-bit dynamically linked shared library x86_64
2. libhdf5.a:         current ar archive random library
3. libhdf5.dylib:     Mach-O 64-bit dynamically linked shared library x86_64
4. libhdf5.la:        libtool library file
5. libhdf5.lai:       libtool library file

I learnt about `lipo' (not what I need, but nice), still have to figure out how to compile the library with 32 bits.

[Phil]

If that's a C library, then you probably used something like configure to prep for the make. If so, see if there's an arch switch, eg,

CFLAGS="-arch i386 -arch x86_64"

[Clemens]

Great, thanks! This is the flag I have been looking for. 

I could indeed build the library with
./configure CFLAGS="-arch i386"

Unfortunately, when I link to the new i386 libhdf5.a, I get these undefined symbols:
___divdi3, ___udivdi3, ___umoddi3.

Scary, three underscores, never seen anything like this... 

Funnily enough, I can link to i386 libhdf5.dylib, but then the binary doesn't work unless I patch the dylib path with install_name_tool. Still impractical.

So if I go the i386 arch route: I can't link a dylib to my program statically, can I?

[Phil]

A search of the Web reveals similar problems. This might help you:

http://embdev.net/topic/129575


Use of install_name_tool is routine enough. I certainly would not let that stop me from using a .dylib in the app bundle. For example, see the last step here that fixes up the executable and the .dylib in Xcode:

https://dl.dropboxusercontent.com/u/28343282/MacXPlatform/PascalDynLibs_3.html#WebMaps

[Clemens]

Great, thanks.

I cannot get the triple underscore symbols to work.  Never mind.  Generally I seem to have less success with *.a libraries than with dylibs.

Thanks for the install_name_root -change hint: works nicely.