bugGNUstep - Bugs: bug #12576, alternative to the...


bug #12576: alternative to the "-framework" flag

Submitter:  Wolfgang Sourdeau <wolfgang>
Submitted:  Wed 06 Apr 2005 03:09:26 AM UTC
Category:  Makefiles Severity:  3 - Normal
Item Group:  Change Request Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


Fri 08 Apr 2005 03:08:13 AM UTC, comment #4: 

Hi again,

The reason why I use -rpath is because it's the only way for me not to install my framework before running my application. That's a personal choice, based on my personal way of doing things. But if you look a bit further on the same line, the "-l" flag is used.
Therefore, if the library is not found in the defaut place (-rpath), it's searched in the regular library paths.

I just tested it and it works.

Regarding the scanning of directories. It does not happen every time a file is compiled. It happens only when the ADDITIONAL_CFLAGS and ADDITIONAL_LDFLAGS are computed in the makefile. However, your commentary made me realize that I omitted  the default system frameworks directories (which is not difficult to do). Actually, all the cryptic make code you can read there is meant to reduce the search path of GCC. I do this by checking that all the mentionned frameworks dirs do exist (using 'wildcard').



Wolfgang Sourdeau <wolfgang>
Wed 06 Apr 2005 11:34:17 AM UTC, comment #3: 

not sure if apple does that, they may do that, but otherwise 'relocatable frameworks' are also supported, which basically link to a path relative to the search path. which you can set through DYLD_FRAMEWORK_PATH

matt rice <ratmice>
Project Member
Wed 06 Apr 2005 11:12:32 AM UTC, comment #2: 

Sorry, the last comment was from me.


Nicola Pero <nico>
Project Member
Wed 06 Apr 2005 11:11:07 AM UTC, comment #1: 

Thanks for your contribution! :-)

It might help some people who might want to use the same code ...

As for the general gnustep-make setup, our current solution is probably better.  The symlinks work very well on Linux.

In the proposed patch, you are using the -rpath option to the linker to hardcode the path to the framework inside the compiled executable.  The problem with this is that it means if you have a framework in System root, compile your application, then deploy the .app file to another machine where the framework is installed but inside Local root, the application stops working.  The same would happen also if on the other machine the location of the System/Local/Network/User roots change!  This is obviously unacceptable; a framework installed in any of System/Local/Network/User root should be immediately usable by any application needing that framework, no matter where System/Local/Network/User are located on that machine.

We do not want to hardcode paths to frameworks/shared libs anywhere.  I think Apple does that; it's a really bad habit they have, and they get away with it just because they control their system so tightly that most stuff can only be installed in a single place.  In the case of Linux, different people tend to install things in different locations, and GNUstep should be enough robust not to go mad if a framework is moved from Local to User for example.

Btw I can't generally see the advantage of the patch ... you're getting away without having to create symlinks in the shared libs directory, but then you can't move your framework (or your framework directories) anywhere without breaking the stuff.  You can't run your binary on another machine where the frameworks are located in a different place on disk ... so it's a regression compared to the current symlink solution!

I'm also a bit uneasy about scanning large number of directories on disk to search for frameworks every time a file is compiled.  The standard shared libs system with all the shared libs in a single directory makes for reasonably efficient compilation.


Wed 06 Apr 2005 03:09:26 AM UTC, original submission:  

Here enclosed, the makefile I include in the (sub)projects's GNUmakefile that requires to be linked to some frameworks.

The syntax to use is as follows:

FRAMEWORKS_DIRS = /whatever/absolute/path/Frameworks ../relative/works/too/but/will/be/converted/Frameworks
FRAMEWORKS = MyFramework YourFramework

including that file will automatically adjust ADDITIONAL_INCLUDE_DIRS and ADDITIONAL_LDFLAGS with computed flags.

Wolfgang Sourdeau <wolfgang>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #2843:  frameworks.make added by wolfgang (469B - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


CC list is empty


There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.





Follow 2 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-04-06 nico Open/ClosedOpen Closed
2005-04-06 wolfgang Attached File- Added frameworks.make, #2385

Back to the top

Powered by Savane 3.9