Created attachment 194 [details]
inet/util/makefile.mk : Patch to ignore .map file

Created attachment 195 [details]
store/util/makefile.mk : Patch to ignore .map file

But the .map-s are extremely usefull as they speed up loading of shared
libraries by limiting the number of global symbols to only these actually
required to be global (now look at the number and size of shared libraries in
OOo).

You might want to take a look at the linker documentation and investigate how
you can pass flags to linker from the compiler. I'm realtively sure they are
actually supported.

One more thing - if you actually decide to take out map files, I guess you
should not patch all teh individual makefile.mk-s but instead modify make rules
in the solenv/inc directory

I definately want to work on this before we release to customer, and have 
raised this with the MIPSpro compiler group.  If they cant provide a suitable 
solution, I will simply write a script which converts them to a compatible 
format.

For now, can we just get it building on IRIX :)

John,

the map files are not just an optimization for shared library loading speed. 
You'll get quite a few hard to find bugs if you just throw away these files on 
Irix without implementing an equivalent mechanism.

The reason for this trouble are double symbols. Under NT all symbols are bound 
locally in a DLL if a symbol is present in this DLL. OpenOffice assumes that 
this behaviour is true also for all shared libraries on Unix which exports just 
a few C functions. These are quite a few like the shared libraries for the 
writer, the calc etc.

All global symbols which are not exported are localized in the map files, which 
results in that all these symbols are bound locally, thus implementing the same 
behaviour as under NT.

Another possibility to achieve this behaviour is to link with -Bsymbolic. But 
this linker switch has some disastrous effects on the ability to catch 
exceptions over shared library boundaries, at least on some platforms.

Shared libraries without mapfiles should never exhibit double symbols, this 
would be a bug.

Heiner

reassign to porting

Technical answer: Bugga.

I had expected as much actually, 'cause it seemed highly un-usual to have a 
wierd format for such a simple task.

Have Sun developed any tools which I could use to perform this?  Are they Open 
Source?  And can I get a slightly more technical (say EBNF) desciption of the 
file format?

John, you might want to take a look at docs.sun.com (search for something called
linker and libraries guide). 

John,

well, our NT developers always call the Unix behavior buggy ...

But to answer your question: The GNU linker has the same ability. They call it
version maps. Mapfiles are also quite useful in performing versioning on symbol
level rep. defining several API's in one shared library. I always thought that
most ELF platforms support these kind of stuff, but obviously I'm wrong.

Heiner

Created attachment 205 [details]
inet/util/ni.map : Example .map in question

Created attachment 206 [details]
store/util/sto.map : Another example .map file

Its not that MIPSpro doesnt support this feature, its merely that I have only 
worked on IRIX/MIPSpro in the last 4 months, hence I am MIPSpro challenged, 
being typically a gcc/linux developer previously.

Sander, is this the document you are refering to ?
http://docs.sun.com/ab2/coll.45.13/LLM/@Ab2PageView/24449?
DwebQuery=linker&oqt=linker&Ab2Lang=C&Ab2Enc=iso-8859-1

I believe so. If you have access to a Linux machine, info ld will show you the
picture from the point of view of gnu linker, but I doubt it is too different...

These global symbols sound like the export symbols list for MIPSpro.
In the ld man page there is:

     -exported_symbol symbol_list
               Used in conjunction with the -shared or -call_shared
               options.  Marks the specified symbols as exported.  Use a
               comma to separate the symbols.  If you specify any exported
               symbols, all unspecified symbols are automatically hidden.
               (C, C++, F77, F90)

     -exports_file file
               Used in conjunction with the -shared or -call_shared
               options.  The specified file must contain a list of symbols
               that should be exported.  The list is comprised of symbol
               names separated by spaces or new-line characters.  Any
               symbols not specifically exported will be automatically
               hidden.  (C, C++, F77, F90)

maybe we could use a script to dynamically convert the .map file to an
export file.  If all the .map files use only global and local * then
the script should be easy enough to generate.

	Victor

This problem is not MIPSpro specific, as gcc on IRIX also uses SGI ld.

I have seen that this problem is also on MACOSX, and they have solved it 
by .IF 's in every applicable makefile.  Surely this can be fixed in the top 
level makefiles, so that for example, should I set LINKNOMAP=1, it will not use 
the MAP settings in each util/makefile.mk

Created attachment 373 [details]
solenv/inv/_tg_shl.mk : Patch to disable .map files on IRIX

This patch is what I want ... but it doesnt seem to be possible using dmake .. 
I get the following error:

solenv/inc/_tg_shl.mk:  line 66:  Error -- .IF do not support &&

Am I using incorrect syntax ... or does it really not handle logical AND's ?

Hi John,

plain dmake doesn't handle &&, || and the like. Ause implemented || because it 
was essentilally a one liner, implementing && correctly would have beeen much 
harder. Just use two conditions one after the other.

Heiner

Created attachment 379 [details]
as above with correct syntax

Patch (ok, a look-alike) appliet to solenv/inc/tg_shl.mk, then re-generated
_tg_shl.mk with mkunroll and tagged both new versions as OO633B

Added myself to CC list. This problem still exists in 638.

changing QA contact from bugs@ to issues@

Created attachment 774 [details]
wrapper around ld to support map files

Created attachment 775 [details]
solenv/inc/_tg_shl.mk - allow IRIX to use map files

I'm not actually sure these should be checked in yet, but I thought
this would be a good spot to
record my progress. 
Basically, what happens is this:
-I have a gcc specs file which looks like this:
    *linker:
     ld.sh
And pass g++ (during the link phase, eg LINK= in the os specific
makefile) -specs=/path/to/gcc_specs
This overrides the default gcc setting for the linker, so call the
ld.sh script (att id 774) instead of collect2. The ld script parses
out  some conflicting options if the map file is used, and converts
the map file to something that is useable by sgi's linker.
It SHOULD be possible to change the gcc specs file to do the parsing,
but I find the specs file 
format very messy and not documented (I DID manage to find
documentation for gcc 3.1 but the 
functionality seems quite different to 2.95.3), and after spending
half a day on it, decided it
was a better use of my time to write this script.... 15 minutes later,
here we are!
Anyway, the script is also a handy place to do a dynamic conversion of
the GNU map file into
something sgi's linker can use.
And, messy as it is, this appears to be working nicely.

Created attachment 776 [details]
wrapper around ld - using gawk rather then awk - some input lines are too long for awk

Hmm, still needs some more work, it looks like some mapfiles only have
a local section (solaris)
or alternatively the Linux ones seem to be able to take wildcards.
Also, gonna have name mangling problems.....

Created attachment 789 [details]
wrapper script, uses -hiddens_file or -exports_file, as is appropriate

OK, this last attachment, works around some more ld problems, and uses
either  -hiddens_file (if only
local symbols are mentioned) or -exports_file (if only exported
symbols are mentioned).
There will need to be some changes to some makefiles for this to work,
as it looks like Linux map
files can have wilcards, so we need to use the solaris ones.

I now have a build which should match the Solaris build in what
symbols are exported from the dso's.

Created attachment 790 [details]
salhelper/source/irgm.map - map file for IRIX

Created attachment 791 [details]
salhelper/source/makefile.mk - support for IRIX map file

Created attachment 792 [details]
psprint/util/makefile.mk - use solaris mapfile on IRIX

Created attachment 820 [details]
ld wrapper - ONLY changes the map file to sgi format

This last wrapper for ld is much better, in that I have gotten rid of
many of the 'sed' lines, by finding
a work-around for some of the ld problems. If we pass ld the flag
-LD_MSG:off=4, we still get the
(misleading) error message, but it does NOT cause an error. So this is
a much cleaner solution,
as all the wrapper does now, is convert the mapfiles to something
sgi's ld can use.

I'm not 100% sure on where to go from here. I have succeded in building
OO using the mapfiles, but it required using a wrapper around ld.
I think I will need to make some changes to configure.in so that
it generates the appropriate wrapper and gcc spec file.... so that 
the wrapper is used transparently.

Also, in the irix specific make file (unxirgm.mk)
LINKVERSIONMAPFLAG=-Wl,-exports_file
needs to be set.

Hi, where are we with this issue? Is it still blocking other GSI
porting efforts?

This works, if you use the last four patches
included in this bug. However, it really needs to be included in the 
configure script, so that it is all done automatically, and I haven't 
got to that yet. 

mh->nick: please work with Ken to do the remaining work.

Accepted. This will require some funky configure work, but its not
urgent right now (Its mostly a performance thing I believe).

Added Miltestone

per issue 106845 sb removed the partial irix port, so this doesn't make sense in
isolation anymore106845

closing