When I try to compile the last snapshot of Lazarus or my own App (using the fpc snapshot DMG 2.2.0)

Shani [milipili] ~/Projects/lazarus %
fpc
Err
18 #16
Free Pascal Compiler version 2.2.0 [2008/02/25] for i386

I have got the following errors :

Shani [milipili] ~/Projects/lazarus % make clean all LCL_PLATFORM=carbon FPC=fpc OPT="-k'-framework' -k'carbon'"

<snip>
unknown stabs type 0xC0 in /usr/local/share/lazarus/lcl/units/i386- darwin/grids.o
unknown stabs type 0xE0 in /usr/local/share/lazarus/lcl/units/i386- darwin/grids.o
Undefined symbols:
"_CGLDestroyContext", referenced from:
GLGRAB_GRABVIAOPENGL$CGDIRECTDISPLAYID$CGRECT$$CGIMAGEREF in glgrab.o
GLGRAB_GRABVIAOPENGL$CGDIRECTDISPLAYID$CGRECT$$CGIMAGEREF in glgrab.o
"_CGLClearDrawable", referenced from:
GLGRAB_GRABVIAOPENGL$CGDIRECTDISPLAYID$CGRECT$$CGIMAGEREF in glgrab.o
GLGRAB_GRABVIAOPENGL$CGDIRECTDISPLAYID$CGRECT$$CGIMAGEREF in glgrab.o
"_CGLCreateContext", referenced from:
GLGRAB_GRABVIAOPENGL$CGDIRECTDISPLAYID$CGRECT$$CGIMAGEREF in glgrab.o
"_CGLSetCurrentContext", referenced from:
GLGRAB_GRABVIAOPENGL$CGDIRECTDISPLAYID$CGRECT$$CGIMAGEREF in glgrab.o
GLGRAB_GRABVIAOPENGL$CGDIRECTDISPLAYID$CGRECT$$CGIMAGEREF in glgrab.o
GLGRAB_GRABVIAOPENGL$CGDIRECTDISPLAYID$CGRECT$$CGIMAGEREF in glgrab.o
"_CGLSetFullScreen", referenced from:
GLGRAB_GRABVIAOPENGL$CGDIRECTDISPLAYID$CGRECT$$CGIMAGEREF in glgrab.o
"_CGLDestroyPixelFormat", referenced from:
GLGRAB_GRABVIAOPENGL$CGDIRECTDISPLAYID$CGRECT$$CGIMAGEREF in glgrab.o
"_CGLChoosePixelFormat", referenced from:
GLGRAB_GRABVIAOPENGL$CGDIRECTDISPLAYID$CGRECT$$CGIMAGEREF in glgrab.o

May I miss something ?

It looks like somebody added an OpenGL dependency to the Carbon widgetset for some reason. Try adding -k'-framework' -k'opengl' when compiling and see if this doesn't fix it.

Thanks.

-Phil

Le Feb 25, 2008 ? 6:49 PM, Hess, Philip J a ?crit :

It looks like somebody added an OpenGL dependency to the Carbon widgetset for some reason. Try adding -k'-framework' -k'opengl' when compiling and see if this doesn't fix it.

Indeed I had not noticed it.
However I have this :

Assembling lazarus
Linking ../lazarus
ld: file not found: opengl
Error: Error while linking
Fatal: There were 1 errors compiling module, stopping

May be another framework or directive for compilation ?

I'm not at my Mac right now, but I believe if you look in /system/library/frameworks you should see opengl.framework. If not, then that might explain the link error.

What version of OS X are you using? I believe the OpenGL framework is a standard part of OS X.

Thanks.

-Phil

Le Feb 25, 2008 ? 7:19 PM, Hess, Philip J a ?crit :

I'm not at my Mac right now, but I believe if you look in /system/ library/frameworks you should see opengl.framework. If not, then that might explain the link error.

The OpenGL frameworks (OpenGL.Framework, and OpenAL.Framework) is present, and working (Homeworld2 and Enigmo UB work fine ^^)

What version of OS X are you using? I believe the OpenGL framework is a standard part of OS X.

I use 10.5.2 Leopard.
Yes OpenGL is part of OS X.

Did you recompile LCL? Maybe you're missing the .o/.ppu files for the new opengl unit that was added to Carbon, although these files should have been included with the snapshot.

Thanks.

-Phil

Le Feb 25, 2008 ? 10:25 PM, Hess, Philip J a ?crit :

Did you recompile LCL? Maybe you're missing the .o/.ppu files for the new opengl unit that was added to Carbon, although these files should have been included with the snapshot.

I made a "clean all" but I have just try to remove .o and .ppu but the result remains the same.

on my 10.4 mini, I added

-k-framework Carbon
-k-framework OpenGL

to my fpc.cfg and it compiles (I succesfully demoed a carbon IDE last weekend)
However, the same weekend someone asked me how to compile Lazarus on his mac (10.5.2 Leopard core2 duo) and it solved the link errors, but not the stab errors.

Marc

Damien,

I had no trouble rebuilding the Laz IDE from within the IDE using today's snapshot (20080225) on Tiger/PowerPC. Also no trouble rebuilding the Laz IDE with:

make all LCL_PLATFORM=carbon OPT="-k-framework -kcarbon -k-framework -kOpenGL"

My apps also compiled and linked okay, although now none of them will run because somebody removed the TextHeight property that is in all of my .lfm files. Lazarus strikes again, I guess.

Unless there's an Intel-specific or Leopard-specific problem, you ought to be able to link okay. Did you install the .dmg snapshot?

Thanks.

-Phil

Le Feb 26, 2008 ? 12:58 AM, Hess, Philip J a ?crit :

Thanks for the OPT, I missed -framework just before -kOpenGL. However, I still have a(nother) problem :)

unknown stabs type 0xE0 in ../units/i386-darwin/codemacroprompt.o unknown stabs type 0xC0 in ../units/i386-darwin/encloseselectiondlg.o unknown stabs type 0xE0 in ../units/i386-darwin/encloseselectiondlg.o ld: cycle in dylib re-exports with /usr/X11R6/lib//libGL.dylib Error: Error while linking
Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
Error: /usr/local/bin/ppc386 returned an error exitcode (normal if you did not specify a source file to be compiled)
make[2]: *** [lazarus] Error 1
make[1]: *** [ide] Error 2
make: *** [ide] Error 2

In the same time, I think a dependancy on the OpenGL framework is not a great idea for an application which does not use it.

Philip J wrote

It looks like somebody added an OpenGL dependency to the Carbon widgetset for some reason.

I added dependency to OpenGL because it's the only possible way to implement screenshot taking. The wiki was updated:

http://wiki.lazarus.freepascal.org/Carbon_Interface#Getting_a_.22carbonproof.22_Lazarus

http://wiki.lazarus.freepascal.org/Carbon_interface_internals#Screenshot_taking

Try adding -k'-framework' -k'opengl' when compiling and see if this doesn't fix it.

Yes, that is the way to fix it.

thanks,

Damien,

I google and found this:

http://developer.apple.com/releasenotes/DeveloperTools/RN-Id/index.html

See this item down in known issues:
#

Re-export cycle detection causes many X11 programs to fail to link

There are two libGL.dylib files. One in /usr/X11/lib and one in /System/Library/Frameworks/OpenGL.framework/Libraries and the former re-exports the latter. The Mac OS X 10.5 linker uses -L paths to search for indirect libraries. The combination of these two causes a re-export cycle which will make the linker error out. The work around is to add: -dylib_file /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib to the link line. The -dylib_file option takes a colon separate pair of paths and instructs the linker where to look for a particular indirect dylib.

#

That looks like the error you're getting.

Maybe you can comment out the OpenGL dependency in the Carbon widgetset for now until this gets worked out.

Thanks.

-Phil

Or remove the X11 dependency, since you're compiling for carbon.

Marc

I was going to suggest that, but it's not clear to me how to do that. In the Inherited tab, it includes /usr/X11R6/lib; /sw/lib even when Carbon is selected. These library paths are read-only and appear to be hardwired into the IDE.

Thanks.

-Phil

2008/2/26 Hess, Philip J :

I was going to suggest that, but it's not clear to me how to do that. In the Inherited tab, it includes /usr/X11R6/lib; /sw/lib even when Carbon is selected. These library paths are read-only and appear to be hardwired into the IDE.

Then this is a bug on the IDE, please report it.

We currently have a mechanism to add extra compiler options based on the widgetset and those darwin hard-coded paths. Those 2 things should be merged together so that we would have a matrix to choose arbitrary extra compiler options based on *both* widgetset and target operating system, making it 2 dimensional.

I don't know if the target architecture and the guest operating system are relevant, but I think not.

thanks,

Or remove the X11 dependency, since you're compiling for carbon.

I will try but I don't know how to do this.
I assume fpcmake should rebuild the Makefile from Makefile.fpc but under OS X when I try to use it I always have the error:

Shani [milipili] /usr/local/share/lazarus/lcl/interfaces/carbon % fpcmake
22
:51 #9
Processing Makefile.fpc
Error: Target "darwin", package "rtl" not found

(In fact I never was able to make fpcmake work)

fpcmake recursively resolves dependancies and needs to find the RTL source or package.fpc files. Easiest is to set FPC_DIR to the FPC source and do a

fpcmake -w -Tall

( -w is to write file, default is/was test, -Tall is process all OSes) this is btw all in the manual.

Le Feb 27, 2008 ? 9:07 AM, Marco van de Voort a ?crit :

Yes but it doesn't work :(

Shani [milipili] /usr/local/share/lazarus % export FPC_DIR=/usr/local/ share/
fpcsrc
9
:47 #21
Shani [milipili] /usr/local/share/lazarus % fpcmake -w - Tall
9
:48 #22
Processing Makefile.fpc
Error: Target "linux", package "rtl" not found
Shani [milipili] /usr/local/share/lazarus % export FPC_DIR=/usr/local/ share/fpcsrc/
packages
Err
1 #23
Shani [milipili] /usr/local/share/lazarus % fpcmake -w - Tall
9
:48 #24
Processing Makefile.fpc
Error: Target "linux", package "rtl" not found
Shani [milipili] /usr/local/share/lazarus % export FPC_DIR=/usr/local/ share/fpcsrc/
rtl
Err
1 #25
Shani [milipili] /usr/local/share/lazarus % fpcmake -w - Tall
9
:48 #26
Processing Makefile.fpc
Error: Target "linux", package "rtl" not found
Shani [milipili] /usr/local/share/lazarus % export FPC_DIR=/usr/local/ share/
fpcsrc
Err
1 #27
Shani [milipili] /usr/local/share/lazarus % fpcmake -w - Tdarwin
9
:49 #28
Processing Makefile.fpc
Error: Target "darwin", package "rtl" not found
Shani [milipili] /usr/local/share/lazarus %
Shani [milipili] /usr/local/share/lazarus % export FPC_DIR=/usr/local/ lib/fpc/
2.2.0
Err
1 #35
Shani [milipili] /usr/local/share/lazarus % fpcmake -w - Tall
9
:52 #36
Processing Makefile.fpc
Error: Target "linux", package "rtl" not found
Shani [milipili] /usr/local/share/lazarus % export FPC_DIR=/usr/local/ lib/fpc/2.2.0/
rtl
Err
1 #37
Shani [milipili] /usr/local/share/lazarus % fpcmake -w - Tall
9
:53 #38
Processing Makefile.fpc
Error: Target "linux", package "rtl" not found

I use the OSX/i386 snapshots.
So I have the following folders :
- /usr/local/share/lazarus
- /usr/local/lib/fpc/2.2.0
- /usr/local/share/fpcsrc

Plus in the /etc/fpc.cfg (not modified) :
-Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget -Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/* -Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/rtl

Le Feb 27, 2008 ? 9:07 AM, Marco van de Voort a ?crit :

fpcmake works fine, just it is FPCDIR, not FPC_DIR :) But in fact there is no need.

The solution has been already provided :
http://developer.apple.com/qa/qa2007/qa1567.html

Consequently, a simple solution is :

make clean all LCL_PLATFORM=carbon FPC=fpc OPT="-k-framework -kcarbon -k-framework -kOpenGL -k'-dylib_file' -k'/System/Library/Frameworks/ OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/ Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib'"

And you have a nice Lazarus Carbon app under Leopard :) However lazarus crashes when exiting.

I have updated the wiki.

Duly reported.

Thanks.

-Phil

is there a reason to put
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib there twice ?

BTW, for clearness, you can also specify:

-k'-framework OpenGL'

Marc

Le Mar 1, 2008 ? 12:32 AM, Marc Weustink a ?crit :

According to the man of ld :
-dylib_file install_name:file_name

Specifies that a dynamic shared library is in a different location than its standard location. Use this option when you link with a library that is dependent on a dynamic library, and the dynamic library is in a location other than its default location. install_name specifies the path where the library normally resides. file_name specifies the path of the library you want to use instead. For example, if you link to a library that depends upon the dynamic library libsys and you have libsys installed in a nondefault location, you would use this option:
-dylib_file /lib/libsys_s.A.dylib:/me/lib/libsys_s.A.dylib.

As far I know, you have to set the two options.

BTW, for clearness, you can also specify: -k'-framework OpenGL'

Yeah... thats clear to me, but soemthing puzzles me. Why do we need to tell the linker that file /some/path/to/foo.dylib is located at exact that path /some/path/to/foo.dylib (how surprising)

Marc

Le Mar 4, 2008 ? 10:30 AM, Marc Weustink a ?crit :

It is like a "stop rule" : when you have to find this lib, you have to use the other lib.

Consequently, when the linker find its two lib :

/usr/X11R6/lib/libGL.dylib
and
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ libGL.dylib
it will be forced to use "/System/Library/Frameworks/OpenGL.framework/ Versions/A/Libraries/libGL.dylib", even if the name is the same in this case.