bugGNUstep - Bugs: bug #25425, Framework resource loading not...

Group
 
 

bug #25425: Framework resource loading not functioning properly on MIPS based Linux

Submitter:  Gregory John Casamento <gcasa>
Submitted:  Wed 28 Jan 2009 04:05:40 PM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Item Group:  Bug Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Declined
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 29 Jan 2009 02:53:54 AM UTC, comment #15: 

Changed title to reflect proper architecture.   Riccardo did a clean rebuild of all of GNUstep on the miniature MIPS machine and it seems to be working now.

Nicola's diagnosis was correct.  Sorry for the false alarm. :)

Gregory John Casamento <gcasa>
Group administrator
Wed 28 Jan 2009 11:20:42 PM UTC, comment #14: 

The way that gnustep-make is building frameworks in your case
is consistent with the way it behaves when symbolic links are not available
on the machine.

On my GNU/Linux machine, I can reproduce your building steps by setting
 
 LN_S = cp -p

in /usr/GNUstep/System/Library/Makefiles/config.make.

If symbolic links are not available, gnustep-make disables versions completely.
The reason is that without symlinks, creating a version and then linking to it
from the top-level would duplicate the entire framework - so frameworks
end up taking a lot of disk space - an effect which is even more annoying
when you're trying to create a Windows self-contained executable and
you're shipping an application, and all the frameworks it depends on
inside the application.

Things should still work, ie, gnustep-base should still be able to load
resources even when versions are disabled.  I'll check that out. :-)

--

But in your case, sorry to insist, but your gnustep-make's configure output
shows LN_S being set to "ln -s" - yet your gnustep-make is behaving as
if LN_S was not set to "ln -s".  So you may want to understand what
is happening.

Here's a few things you could try --

what is the output of

 cd Addresses
 make print-gnustep-make-help

and to get the version of the installed gnustep-make, try

 grep GNUSTEP_MAKE_VERSION /usr/GNUstep/System/Library/Makefiles/config-noarch.mak

or just look manually into the installed config-noarch.make and check
the GNUSTEP_MAKE_VERSION.

Thanks

Nicola Pero <nico>
Group Member
Wed 28 Jan 2009 11:05:42 PM UTC, comment #13: 

Where can I find the version in the installed copy of GNUstep-make?

Gregory John Casamento <gcasa>
Group administrator
Wed 28 Jan 2009 11:04:28 PM UTC, comment #12: 

Here is the ls -lR... this happens with all frameworks...

root@dhcppc1:/usr/GNUstep/Local/Library/Frameworks/Addresses.framework# ls -lR
.:
total 2122
-rwxr-xr-x 1 root root 542014 Jan 28 15:38 Addresses
drwxr-xr-x 1 root root   2048 Jan 28 15:34 Headers
drwxr-xr-x 1 root root   2048 Jan 28 15:34 Resources
-rwxr-xr-x 1 root root 542014 Jan 28 15:38 libAddresses.so
-rwxr-xr-x 1 root root 542014 Jan 28 15:38 libAddresses.so.0
-rwxr-xr-x 1 root root 542014 Jan 28 15:38 libAddresses.so.0.0.1

./Headers:
total 36
-rw-r--r-- 1 root root 1583 Jan 28 15:34 ADAddressBook.h
-rw-r--r-- 1 root root 1447 Jan 28 15:34 ADConverter.h
-rw-r--r-- 1 root root  966 Jan 28 15:34 ADEnvelopeAddressBook.h
-rw-r--r-- 1 root root 4986 Jan 28 15:34 ADGlobals.h
-rw-r--r-- 1 root root 1396 Jan 28 15:34 ADGroup.h
-rw-r--r-- 1 root root 1318 Jan 28 15:34 ADImageLoading.h
-rw-r--r-- 1 root root 1535 Jan 28 15:34 ADLocalAddressBook.h
-rw-r--r-- 1 root root 1662 Jan 28 15:34 ADMultiValue.h
-rw-r--r-- 1 root root  583 Jan 28 15:34 ADPListConverter.h
-rw-r--r-- 1 root root 1871 Jan 28 15:34 ADPerson.h
-rw-r--r-- 1 root root 1689 Jan 28 15:34 ADPlugin.h
-rw-r--r-- 1 root root  765 Jan 28 15:34 ADPublicAddressBook.h
-rw-r--r-- 1 root root 1797 Jan 28 15:34 ADRecord.h
-rw-r--r-- 1 root root 1125 Jan 28 15:34 ADSearchElement.h
-rw-r--r-- 1 root root 1868 Jan 28 15:34 ADTypedefs.h
-rw-r--r-- 1 root root  801 Jan 28 15:34 ADVCFConverter.h
-rw-r--r-- 1 root root 5922 Jan 28 15:34 AddressBook.h
-rw-r--r-- 1 root root  877 Jan 28 15:34 Addresses.h

./Resources:
total 11
drwxr-xr-x 1 root root 2048 Jan 28 15:38 Dutch.lproj
drwxr-xr-x 1 root root 2048 Jan 28 15:38 English.lproj
drwxr-xr-x 1 root root 2048 Jan 28 15:38 French.lproj
drwxr-xr-x 1 root root 2048 Jan 28 15:38 German.lproj
-rw-r--r-- 1 root root  488 Jan 28 15:38 Info-gnustep.plist
-rw-r--r-- 1 root root  413 Jan 28 15:38 ScriptingInfo.plist
drwxr-xr-x 1 root root 2048 Jan 28 15:38 Spanish.lproj

./Resources/Dutch.lproj:
total 2
-rwxr-xr-x 1 root root 1702 Jan 28 15:38 PropertiesAndLabels.strings

./Resources/English.lproj:
total 2
-rw-r--r-- 1 root root 1679 Jan 28 15:38 PropertiesAndLabels.strings

./Resources/French.lproj:
total 2
-rw-r--r-- 1 root root 1844 Jan 28 15:38 PropertiesAndLabels.strings

./Resources/German.lproj:
total 2
-rw-r--r-- 1 root root 1830 Jan 28 15:38 PropertiesAndLabels.strings

./Resources/Spanish.lproj:
total 2
-rw-r--r-- 1 root root 1960 Jan 28 15:38 PropertiesAndLabels.strings
root@dhcppc1:/usr/GNUstep/Local/Library/Frameworks/Addresses.framework#

Gregory John Casamento <gcasa>
Group administrator
Wed 28 Jan 2009 10:59:39 PM UTC, comment #11: 


--- 
root@dhcppc1:/usr/GNUstep/System/Library/Makefiles# make -v
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for mipsel-unknown-linux-gnu
---
root@dhcppc1:/home/gnustep-dev/core/make# more Version
# This file is included in various Makefile's to get version information.
# Compatible with Bourne shell syntax, so it can included there too.

# The version number of this release.
GNUSTEP_MAKE_MAJOR_VERSION=2
GNUSTEP_MAKE_MINOR_VERSION=0
GNUSTEP_MAKE_SUBMINOR_VERSION=8
GNUSTEP_MAKE_VERSION=${GNUSTEP_MAKE_MAJOR_VERSION}.${GNUSTEP_MAKE_MINOR_VERSION}.${GNUSTEP_MAKE_SUBMINOR_VERSION}
--
GNUSTEP_MAKEFILES=/usr/GNUstep/System/Library/Makefiles

Gregory John Casamento <gcasa>
Group administrator
Wed 28 Jan 2009 08:48:42 PM UTC, comment #10: 

I'm confused by your logs - the way gnustep-make configured
itself does not match the way it is behaving. :-(

The only explanation I could think of is that the gnustep-make
you are using to compile and install is not the gnustep-make
v2.0.8 that you installed, but some older version - that maybe
was lying around ?

To understand this, you could for example consider the version

Your configure log shows that you're using gnustep-make v2.0.8,
and GNU make 3.81, which supports the info function.

In that case, every time you type 'make' you should see
the message

"This is gnustep-make 2.0.8. Type 'make print-gnustep-make-help' for help."

but in your installation log, that line is missing - meaning
you're not using gnustep-make 2.0.8 (or, I suppose, you're not
using GNU make 3.81).

Can you check the value of the shell variable GNUSTEP_MAKEFILES
and what directory it points to ?  Is that the gnustep-make
v2.0.8 installation that you want to use ?

Thanks

Nicola Pero <nico>
Group Member
Wed 28 Jan 2009 07:50:47 PM UTC, comment #9: 

Greg,
can you please post the output of ls -lR of the framework so that others can take a look at it's anatomy and if parts are built correctly?

BTW: it is a MIPS (not ARM) machine.

Nikolaus Schaller <hns>
Group Member
Wed 28 Jan 2009 06:43:10 PM UTC, comment #8: 

Just FYI, this does happen on all other frameworks.

Gregory John Casamento <gcasa>
Group administrator
Wed 28 Jan 2009 06:41:58 PM UTC, comment #7: 

Done.

Gregory John Casamento <gcasa>
Group administrator
Wed 28 Jan 2009 05:32:52 PM UTC, comment #6: 

Can you go in the framework that doesn't work, and do

make distclean

make messages=yes
make messages=yes install

and send me the output ?

Thanks

Nicola Pero <nico>
Group Member
Wed 28 Jan 2009 05:10:15 PM UTC, comment #5: 

I suppose getting it from the top level would, if a given application was looking for a given version of the library resources... getting it from the top level at that point could cause issues.

So, it does sound like a problem with the installation of the framework at this point.

GC


Gregory John Casamento <gcasa>
Group administrator
Wed 28 Jan 2009 05:03:14 PM UTC, comment #4: 

It sounds to me like a problem with the installation of the framework rather than a problem with the loading mechanism.

If I understand frameworks correctly, all the resources are supposed to be in subdirectories of the versions folder, and the loading code is supposed to load in the data from the subdirectory whose version matches the running code.

The top-level Resources folder is meant to be a link to the most recently installed data as a convenience for human beings and software development tools looking to locate the latest information ... because that's what you are going to use when you build an appplication.

ie one lookup is for runtime use by code which has lnked a framework, and the other location is for builtime use.

So loading resources for a running application from the top-level directory would break versioning and thus the library should never do it.

Of course, I may be misunderstanding framework versioning here ...


Richard Frith-Macdonald <CaS>
Group Member
Wed 28 Jan 2009 04:46:21 PM UTC, comment #3: 

Could this be due to a limitation in the ARM Linux linker?  Can it not handle dynamic links to libraries?

I also noticed that in the Libraries directory the libs there are copies, not links, to the ones in the frameworks.  This seems to indicate that the linker can't handle this functionality.

Also...  I think that NSBundle should look into the Resources folder at the top level of the framework bundle instead of looking directly in Versions.   That, I believe, would solve this issue.

Thanks, GC

Gregory John Casamento <gcasa>
Group administrator
Wed 28 Jan 2009 04:43:27 PM UTC, comment #2: 

Here's the uname -a output:
---
Linux dhcppc1 2.4.20-celf3 #1 Fri Sep 5 21:48:01 HKT 2008 mips GNU/Linux

Make configure output...
---
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g...
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl.exe... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking whether we are using the GNU C++ compiler... no
checking whether g++ accepts -g... no
checking build system type... mipsel-unknown-linux-gnu
checking host system type... mipsel-unknown-linux-gnu
checking target system type... mipsel-unknown-linux-gnu
checking for library combo... gnu-gnu-gnu
checking for apple compiler flags... yes
checking for ar... ar
checking for dlltool... no
checking for ranlib... ranlib
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for gnutar... no
checking for gtar... no
checking for chown... chown
checking if we should enable strict gnustep-make version 2 mode by default... no
checking for GNUstep filesystem layout to use... none specified: we use 'gnustep'
checking if we manage to import the filesystem layout configuration... ok
checking for prefix... /usr/GNUstep
checking for GNUstep configuration file to use... /etc/GNUstep/GNUstep.conf
checking if we should import an existing configuration file... no
checking if the obsolete --with-system-root option was used... no: good
checking if the obsolete --with-local-root option was used... no: good
checking if the obsolete --with-network-root option was used... no: good
checking for user config file to use... .GNUstep.conf
checking if the obsolete --with-user-dir option was used... no: good
checking for user defaults dir to use... GNUstep/Defaults
checking for GNUSTEP_MAKEFILES to use... /usr/GNUstep/System/Library/Makefiles
checking for flattened directory structure... yes
configure: Now printing the filesystem layout configuration.
checking for System Applications directory... /usr/GNUstep/System/Applications
checking for System Admin Applications directory... /usr/GNUstep/System/Applications/Admin
checking for System Web Applications directory... /usr/GNUstep/System/Library/WebApplications
checking for System Tools directory... /usr/GNUstep/System/Tools
checking for System Admin Tools directory... /usr/GNUstep/System/Tools/Admin
checking for System Library directory... /usr/GNUstep/System/Library
checking for System Headers directory... /usr/GNUstep/System/Library/Headers
checking for System Libraries directory... /usr/GNUstep/System/Library/Libraries
checking for System Documentation directory... /usr/GNUstep/System/Library/Documentation
checking for System Info Documentation directory... /usr/GNUstep/System/Library/Documentation/info
checking for System Man Documentation directory... /usr/GNUstep/System/Library/Documentation/man
checking for Network Applications directory... /usr/GNUstep/Local/Applications
checking for Network Admin Applications directory... /usr/GNUstep/Local/Applications/Admin
checking for Network Web Applications directory... /usr/GNUstep/Local/Library/WebApplications
checking for Network Tools directory... /usr/GNUstep/Local/Tools
checking for Network Admin Tools directory... /usr/GNUstep/Local/Tools/Admin
checking for Network Library directory... /usr/GNUstep/Local/Library
checking for Network Headers directory... /usr/GNUstep/Local/Library/Headers
checking for Network Libraries directory... /usr/GNUstep/Local/Library/Libraries
checking for Network Documentation directory... /usr/GNUstep/Local/Library/Documentation
checking for Network Info Documentation directory... /usr/GNUstep/Local/Library/Documentation/info
checking for Network Man Documentation directory... /usr/GNUstep/Local/Library/Documentation/man
checking for Local Applications directory... /usr/GNUstep/Local/Applications
checking for Local Admin Applications directory... /usr/GNUstep/Local/Applications/Admin
checking for Local Web Applications directory... /usr/GNUstep/Local/Library/WebApplications
checking for Local Tools directory... /usr/GNUstep/Local/Tools
checking for Local Admin Tools directory... /usr/GNUstep/Local/Tools/Admin
checking for Local Library directory... /usr/GNUstep/Local/Library
checking for Local Headers directory... /usr/GNUstep/Local/Library/Headers
checking for Local Libraries directory... /usr/GNUstep/Local/Library/Libraries
checking for Local Documentation directory... /usr/GNUstep/Local/Library/Documentation
checking for Local Info Documentation directory... /usr/GNUstep/Local/Library/Documentation/info
checking for Local Man Documentation directory... /usr/GNUstep/Local/Library/Documentation/man
checking for User Applications directory... GNUstep/Applications
checking for User Admin Applications directory... GNUstep/Applications/Admin
checking for User Web Applications directory... GNUstep/Library/WebApplications
checking for User Tools directory... GNUstep/Tools
checking for User Admin Tools directory... GNUstep/Tools/Admin
checking for User Library directory... GNUstep/Library
checking for User Headers directory... GNUstep/Library/Headers
checking for User Libraries directory... GNUstep/Library/Libraries
checking for User Documentation directory... GNUstep/Library/Documentation
checking for User Info Documentation directory... GNUstep/Library/Documentation/info
checking for User Man Documentation directory... GNUstep/Library/Documentation/man
checking for System User directory... /home
checking for Network User directory... /home
checking for Local User directory... /home
checking for custom shared objc library... NONE
checking whether objc has thread support... yes: -lpthread
checking whether we should use native ObjC exceptions... not requested by user
checking for the GCC version... version: 4.1
checking if the compiler supports autodependencies... yes: gcc version is 4.1 >= 3.0
checking if the compiler supports precompiled headers... no: gcc 4.1 is often shipped with broken precompiled headers
checking if the compiler requires -shared flag to build for Solaris... yes: gcc version is 4.1 >= 4.0
checking for gmake... no
checking for gnumake... no
checking for make... make
checking for the GNU Make version... version: 3.81
checking if GNU Make has the info function... yes
checking if we should strip makefiles after installation... no
checking for the version of gnustep-make we are compiling... 2.0.8
checking for latex2html... no
configure: creating ./config.status
config.status: creating config-noarch.make
config.status: creating config.make
config.status: creating openapp
config.status: creating opentool
config.status: creating executable.template
config.status: creating GNUmakefile
config.status: creating GNUstep.conf
config.status: creating GNUstep-strict-v2.conf
config.status: creating GNUstep.sh
config.status: creating GNUstep.csh
config.status: creating fixpath.sh
config.status: creating gnustep-make.spec
config.status: creating gnustep-config
config.status: creating filesystem.make
config.status: creating filesystem.sh
config.status: creating filesystem.csh
config.status: executing default commands
root@dhcppc1:/home/gnustep-dev/core/make#



(file #17347)

Gregory John Casamento <gcasa>
Group administrator
Wed 28 Jan 2009 04:16:05 PM UTC, comment #1: 

What operating system is being used ?

Maybe symbolic links don't work or are not used on that operating system ?

Also, can you include the results of gnustep-make's ./configure, and any
other output/raw data that can help with figuring it out ? :-)

Thanks

Nicola Pero <nico>
Group Member
Wed 28 Jan 2009 04:05:40 PM UTC, original submission:  

When loading a resource from a framework on an ARM based Linux machine, the resource is not found.

This appears to be because the directory called "Versions" is not there and the NSBundle code assumes that it will be.   The steps to reproduce this are:

On an ARM based machine do the following...

1) Get the Addresses code from the gap project...
2) Build and run address manager

RESULT: It will try to load Label.dict from the Resources directory under "Versions" but it doesn't exist.
EXPECTED: The Label.dict file should be loaded properly.

Shouldn't the NSBundle code be looking in "Resources" for this anyway since Resources will be linked to the proper framework version through the symbolic link?  Otherwise it will simply get the first version that it finds.

Gregory John Casamento <gcasa>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #17348:  installation.log added by gcasa (12KiB - text/x-log - Typescript log of install as requested.)
file #17347:  config.log added by gcasa (24KiB - text/x-log - Configure log from ARM Linux machine.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hns (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by nico (Posted a comment)
  • -email is unavailable- added by gcasa (Submitted the item)
  •  

    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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-01-29 gcasa StatusNone Invalid
        Open/ClosedOpen Declined
    2009-01-29 gcasa SummaryFramework resource loading not functioning properly on ARM based Linux Framework resource loading not functioning properly on MIPS based Linux
    2009-01-28 nico SummaryFramework resource loading not functioning properly on MIPS based Linux Framework resource loading not functioning properly on ARM based Linux
    2009-01-28 gcasa SummaryFramework resource loading not functioning properly on ARM based Linux Framework resource loading not functioning properly on MIPS based Linux
    2009-01-28 gcasa Attached File- Added installation.log, #17348
    2009-01-28 gcasa Attached File- Added config.log, #17347

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code