|
Replies:
21
-
Last Post:
Mar 12, 2008 3:45 AM
by: casper
|
|
|
Posts:
156
From:
US
Registered:
3/14/06
|
|
|
|
PSARC/2008/179 cross link-editor
Posted:
Mar 5, 2008 4:40 PM
|
|
I am sponsoring the following self-reviewed case for myself.
I believe it qualifies for self review: The changes have limited
scope, are similar to existing features, and preserve full backward
compatibility.
Release Binding: Patch/Micro
'-z target=' ld option: Committed
DT_SUNW_LDMACH dynamic tag Committed
---------------------------------------------------------------------------
Overview
--------
The integration of
6671255 link-editor should support cross linking
will extend the Solaris link-editor from being a purely native
linker, to a cross linker. This means that a linker running
on any Solaris host will be able to link objects for any other
supported target system. We see two benefits:
- Simplify porting of OpenSolaris to new architectures.
The Solaris code makes heavy use of the unique features
supported by Solaris link-editor, many of which were
developed for just that purpose. Ports of OpenSolaris
usually attempt to bootstrap using the GNU ld, which
already supports cross linking, but which does not support
all the Solaris features we use. The ability to add a new
target to the Solaris linker using a non-native host, and then
to use that linker to bootstrap the rest of the system is
a significant shortcut.
- Allows the use of fast/cheap commodity desktop systems to
build objects for other systems, be they large expensive
systems, or small embedded devices.
New ld command option: -z target=XXX
------------------------------------
Traditionally, ld establishes the class (whether the object is 32
or 64-bit) of the object being generated by examining the first ELF
object processed from the command line. In the case where an object
is being built solely from an archive library or a mapfile, the -64
command line option is available to explicitly override this default.
We extend this mechanism to also determine the machine type of the
object to produce:
- The class and machine type of the resulting object
default to those of the first ELF object processed
from the command line.
- The new '-z target=' command line option can be
used to explicitly specify the machine type.
Supported target types will be 'sparc', and 'x86'.
New ELF Dynamic Section tag: DT_SUNW_LDMACH
-------------------------------------------
A cross link-editor has to contend with byte order and alignment
issues not encountered by a native link-editor. Errors in the code
that handles this can lie latent in a native linker and only cause
problems when the linker host and target have different requirements.
When debugging linker issues, it will be important to be able to
reliably determine the machine type of the linker that produced
the object.
The link-editor will tag every dynamic object it produces with a
DT_SUNW_LDMACH dynamic section entry. DT_SUNW_LDMACH is an integer
containing the EM_* ELF machine type code for the linker that produced
the object. This information is not used by the runtime linker, and
exists purely as documentation. It is easily displayed via dump,
elfdump, or elfedit. For example, given a sparc a.out binary
built using the Solaris X86 cross linker:
% elfdump a.out | grep EM_
e_machine: EM_SPARC32PLUS e_version: EV_CURRENT
[27] SUNW_LDMACH 0x3 EM_386
Even in a native linking situation, the presence of SUNW_LDMACH
can be informative, as it allows us to determine whether the 32-bit
or 64-bit version of the link-editor was employed.
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
Posts:
1,495
From:
Registered:
5/18/05
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 5, 2008 8:20 PM
in response to: alib
|
|
Ali Bahrami wrote:
> The link-editor will tag every dynamic object it produces with a
> DT_SUNW_LDMACH dynamic section entry. DT_SUNW_LDMACH is an integer
Any chance of updating file(1) to know about this info?
-John
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
156
From:
US
Registered:
3/14/06
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 6, 2008 10:27 AM
in response to: plocher
|
|
John Plocher wrote:
> Ali Bahrami wrote:
>> The link-editor will tag every dynamic object it produces with a
>> DT_SUNW_LDMACH dynamic section entry. DT_SUNW_LDMACH is an integer
>
>
> Any chance of updating file(1) to know about this info?
>
> -John
>
My feeling is that this wouldn't be the right thing. In principle,
a cross compiled object should be identical to the same object built
natively, and isn't a primary attribute in same way that the information
displayed by 'file' is.
DT_SUNW_LDMACH is really diagnostic information, of interest only when
the compiler/linker have done something wrong and we're trying to root
cause the issue. elfdump or elfedit are the best tools for getting that
this sort of information.
- Ali
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
1,495
From:
Registered:
5/18/05
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 6, 2008 10:59 AM
in response to: alib
|
|
Ali Bahrami wrote:
> My feeling is that this wouldn't be the right thing. In principle,
> a cross compiled object should be identical to the same object built
> natively, and isn't a primary attribute in same way that the information
> displayed by 'file' is.
If I'm crosscompiling a distro for a set of architectures,
I'm likely to have object files for each:
./foo.c
./obj-x86/foo.o
./obj-x86/foo
./obj-sparc/foo.o
./obj-sparc/foo
In this case, the file command tells me some info; the question
is if it is sufficient for simple makefile sanity checking (did
I manage to build the right mix of stuff?)
I'm happy with whatever path you take - I just wanted to check
to see if there was value there...
-John
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
156
From:
US
Registered:
3/14/06
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 6, 2008 11:36 AM
in response to: plocher
|
|
John Plocher wrote:
> Ali Bahrami wrote:
>> My feeling is that this wouldn't be the right thing. In principle,
>> a cross compiled object should be identical to the same object built
>> natively, and isn't a primary attribute in same way that the information
>> displayed by 'file' is.
>
> If I'm crosscompiling a distro for a set of architectures,
> I'm likely to have object files for each:
>
> ./foo.c
> ./obj-x86/foo.o
> ./obj-x86/foo
> ./obj-sparc/foo.o
> ./obj-sparc/foo
>
> In this case, the file command tells me some info; the question
> is if it is sufficient for simple makefile sanity checking (did
> I manage to build the right mix of stuff?)
>
> I'm happy with whatever path you take - I just wanted to check
> to see if there was value there...
>
> -John
>
If you are cross compiling a distro, and you want to verify that
the right type of object got built, I think the information from 'file'
tells you what you want. The point is to ensure that a certain type
of object got built, not to verify where it was built, right?
However, if you did want to verify where an object was built, elfedit
makes that easy. For example, consider the sparc binary 'foo'
that I built recently using my X86 cross linker:
% file foo
foo: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped
% LDMACH=`elfedit -r -osimple -e 'dyn:sunw_ldmach' foo`
% echo $LDMACH
EM_386
In fact, elfedit makes parsing that 'file' output easier too:
% MACH=`elfedit -r -osimple -e 'ehdr:e_machine' foo`
% echo $MACH
EM_SPARC32PLUS
which easier to script against than the output from 'file'.
Let me know if this doesn't address your question. Thanks...
- Ali
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
1,495
From:
Registered:
5/18/05
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 6, 2008 12:47 PM
in response to: alib
|
|
Ali Bahrami wrote:
> John Plocher wrote:
>> I'm happy with whatever path you take - I just wanted to check
> Let me know if this doesn't address your question. Thanks...
As I said, I'm happy; thanks for the additional clarification.
-John
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
156
From:
US
Registered:
3/14/06
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 6, 2008 11:36 AM
in response to: plocher
|
|
John Plocher wrote:
> Ali Bahrami wrote:
>> My feeling is that this wouldn't be the right thing. In principle,
>> a cross compiled object should be identical to the same object built
>> natively, and isn't a primary attribute in same way that the information
>> displayed by 'file' is.
>
> If I'm crosscompiling a distro for a set of architectures,
> I'm likely to have object files for each:
>
> ./foo.c
> ./obj-x86/foo.o
> ./obj-x86/foo
> ./obj-sparc/foo.o
> ./obj-sparc/foo
>
> In this case, the file command tells me some info; the question
> is if it is sufficient for simple makefile sanity checking (did
> I manage to build the right mix of stuff?)
>
> I'm happy with whatever path you take - I just wanted to check
> to see if there was value there...
>
> -John
>
If you are cross compiling a distro, and you want to verify that
the right type of object got built, I think the information from 'file'
tells you what you want. The point is to ensure that a certain type
of object got built, not to verify where it was built, right?
However, if you did want to verify where an object was built, elfedit
makes that easy. For example, consider the sparc binary 'foo'
that I built recently using my X86 cross linker:
% file foo
foo: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped
% LDMACH=`elfedit -r -osimple -e 'dyn:sunw_ldmach' foo`
% echo $LDMACH
EM_386
In fact, elfedit makes parsing that 'file' output easier too:
% MACH=`elfedit -r -osimple -e 'ehdr:e_machine' foo`
% echo $MACH
EM_SPARC32PLUS
which easier to script against than the output from 'file'.
Let me know if this doesn't address your question. Thanks...
- Ali
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Garrett D'Amore
gdamore@sun.com
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 5, 2008 8:36 PM
in response to: alib
|
|
Can I just say, "yay". :-)
Now if only we could get cross-compilation working....
-- Garrett
Ali Bahrami wrote:
> I am sponsoring the following self-reviewed case for myself.
>
> I believe it qualifies for self review: The changes have limited
> scope, are similar to existing features, and preserve full backward
> compatibility.
>
> Release Binding: Patch/Micro
> '-z target=' ld option: Committed
> DT_SUNW_LDMACH dynamic tag Committed
>
> ---------------------------------------------------------------------------
>
>
> Overview
> --------
>
> The integration of
>
> 6671255 link-editor should support cross linking
>
> will extend the Solaris link-editor from being a purely native
> linker, to a cross linker. This means that a linker running
> on any Solaris host will be able to link objects for any other
> supported target system. We see two benefits:
>
> - Simplify porting of OpenSolaris to new architectures.
>
> The Solaris code makes heavy use of the unique features
> supported by Solaris link-editor, many of which were
> developed for just that purpose. Ports of OpenSolaris
> usually attempt to bootstrap using the GNU ld, which
> already supports cross linking, but which does not support
> all the Solaris features we use. The ability to add a new
> target to the Solaris linker using a non-native host, and then
> to use that linker to bootstrap the rest of the system is
> a significant shortcut.
>
> - Allows the use of fast/cheap commodity desktop systems to
> build objects for other systems, be they large expensive
> systems, or small embedded devices.
>
>
>
> New ld command option: -z target=XXX
> ------------------------------------
>
> Traditionally, ld establishes the class (whether the object is 32
> or 64-bit) of the object being generated by examining the first ELF
> object processed from the command line. In the case where an object
> is being built solely from an archive library or a mapfile, the -64
> command line option is available to explicitly override this default.
> We extend this mechanism to also determine the machine type of the
> object to produce:
>
> - The class and machine type of the resulting object
> default to those of the first ELF object processed
> from the command line.
>
> - The new '-z target=' command line option can be
> used to explicitly specify the machine type.
> Supported target types will be 'sparc', and 'x86'.
>
>
>
> New ELF Dynamic Section tag: DT_SUNW_LDMACH
> -------------------------------------------
>
> A cross link-editor has to contend with byte order and alignment
> issues not encountered by a native link-editor. Errors in the code
> that handles this can lie latent in a native linker and only cause
> problems when the linker host and target have different requirements.
> When debugging linker issues, it will be important to be able to
> reliably determine the machine type of the linker that produced
> the object.
>
> The link-editor will tag every dynamic object it produces with a
> DT_SUNW_LDMACH dynamic section entry. DT_SUNW_LDMACH is an integer
> containing the EM_* ELF machine type code for the linker that produced
> the object. This information is not used by the runtime linker, and
> exists purely as documentation. It is easily displayed via dump,
> elfdump, or elfedit. For example, given a sparc a.out binary
> built using the Solaris X86 cross linker:
>
> % elfdump a.out | grep EM_
> e_machine: EM_SPARC32PLUS e_version: EV_CURRENT
> [27] SUNW_LDMACH 0x3 EM_386
>
> Even in a native linking situation, the presence of SUNW_LDMACH
> can be informative, as it allows us to determine whether the 32-bit
> or 64-bit version of the link-editor was employed.
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
156
From:
US
Registered:
3/14/06
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 6, 2008 10:20 AM
in response to: Garrett D'Amore
|
|
Several questions have come in publicly and privately regarding
cross compiling, whether our compilers support cross compilation,
and whether I've made any attempt to cross build ON. Let me fill
in some of those details.
A cross link-editor is just one part of the larger build picture. It
is a significant step, but there is much left to do. For example, to
cross build an ON nightly build, we will need cross-capable:
- compilers, assemblers, and any related tool chain components
- Related build tools (mcs?)
- ctfconvert
- makefiles will probably need adjustment
- elfsign
Some of these are hard, others easy, but clearly there's work left to do.
And no doubt there are 5-10 additional things that I'm not thinking of at
the moment. As much as I'd love to use my fast amd64 desktop box to do my
nightly sparc builds, it's not something that will happen over night.
The compiler/assembler is the biggest remaining piece of the puzzle.
gcc can be built as a cross compiler, but as far as I know, the standard
Sun Studio compilers are native-only. I am aware of one cross compilation project
going on within our compiler group, and I know there is wider interest in
the subject, so it is certainly possible that they might move in that direction
now that there is a linker to use. This is a business decision they need to
make.
My primary focus in turning ld into a cross link-editor has therefore
been to establish the internal framework for cross-support, and to ensure
that native operation doesn't suffer. Used as a cross linker:
- I've built small cross programs manually, but using two terminal
windows (one x86, the other sparc): Compile in one, link in the
other, return to the first to run the result.
- The cross link-editor prototype was used in the cross
compilation project I mentioned above.
- Ali
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Garrett D'Amore
gdamore@sun.com
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 6, 2008 11:02 AM
in response to: alib
|
|
Ali,
Thanks for the clarification and your comments, not to mention your
efforts here!
I certainly hope the compiler group will pick up this particular torch.
The utility of being able to cross-compile just seems too compelling to
ignore. (Heck, they'd probably like to be able to cross-compile their
own tool chain -- I gotta think that waiting around for SPARC builds
when much faster or cheaper x86 hardware is readily obtainable is
something that they'd like to avoid.
Given that ability, and source code for the compilers themselves (/me
wishful thinking?) it becomes a lot easier to start considering some of
the different machine ports that have eluded us to date -- MIPS, ARM,
etc. (and the existing PowerPC and S/390 ports probably get a big
benefit as well.)
Self-hosting is a huge barrier to entry in contemplating a port to a new
machine, and the lack of such a barrier is one of the main reasons that
both Linux and NetBSD have been ported to so many different and
interesting architectures.
-- Garrett
Ali Bahrami wrote:
> Several questions have come in publicly and privately regarding
> cross compiling, whether our compilers support cross compilation,
> and whether I've made any attempt to cross build ON. Let me fill
> in some of those details.
>
> A cross link-editor is just one part of the larger build picture. It
> is a significant step, but there is much left to do. For example, to
> cross build an ON nightly build, we will need cross-capable:
>
> - compilers, assemblers, and any related tool chain components
> - Related build tools (mcs?)
> - ctfconvert
> - makefiles will probably need adjustment
> - elfsign
>
> Some of these are hard, others easy, but clearly there's work left to do.
> And no doubt there are 5-10 additional things that I'm not thinking of at
> the moment. As much as I'd love to use my fast amd64 desktop box to do my
> nightly sparc builds, it's not something that will happen over night.
>
> The compiler/assembler is the biggest remaining piece of the puzzle.
> gcc can be built as a cross compiler, but as far as I know, the standard
> Sun Studio compilers are native-only. I am aware of one cross
> compilation project
> going on within our compiler group, and I know there is wider interest in
> the subject, so it is certainly possible that they might move in that
> direction
> now that there is a linker to use. This is a business decision they
> need to
> make.
>
> My primary focus in turning ld into a cross link-editor has therefore
> been to establish the internal framework for cross-support, and to ensure
> that native operation doesn't suffer. Used as a cross linker:
>
> - I've built small cross programs manually, but using two terminal
> windows (one x86, the other sparc): Compile in one, link in the
> other, return to the first to run the result.
>
> - The cross link-editor prototype was used in the cross
> compilation project I mentioned above.
> - Ali
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Joseph Kowalski
jek3@sun.com
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 6, 2008 12:23 PM
in response to: Garrett D'Amore
|
|
Garrett D'Amore wrote:
>
> Ali,
>
> Thanks for the clarification and your comments, not to mention your
> efforts here!
>
> I certainly hope the compiler group will pick up this particular
> torch. The utility of being able to cross-compile just seems too
> compelling to ignore. (Heck, they'd probably like to be able to
> cross-compile their own tool chain -- I gotta think that waiting
> around for SPARC builds when much faster or cheaper x86 hardware is
> readily obtainable is something that they'd like to avoid.
All I can say is "don't hold your breath". I first picked up "this
particular torch" in around 1990. I suspect that others picked it up
before then. The compiler group had always responded, "not worth the
test matrix". It also seems that we were the major requestors - it
seems that our ISVs didn't trust cross-compiling (when it comes to final
builds, would we?).
Maybe something has changed, but I don't suspect anything has.
When I first made this request, it was because we wanted to do the lame
x86 builds on the wizzy SPARC machines. :-)
At that time, even "lame" x86 machines were $4000. The now much lower
cost makes having two machines even more attractive.
I'd find other windmills to tilt at.
Just my historical $.02.
- jek3
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 7, 2008 12:43 AM
in response to: Joseph Kowalski
|
|
>When I first made this request, it was because we wanted to do the lame
>x86 builds on the wizzy SPARC machines. :-)
But Sun did sell cross compilers at some point (in the m68k to SPARC era)
Casper
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
3,783
From:
DE
Registered:
4/27/05
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 11, 2008 7:24 AM
in response to: Joseph Kowalski
|
|
Joseph Kowalski <jek3 at sun dot com> wrote:
> All I can say is "don't hold your breath". I first picked up "this
> particular torch" in around 1990. I suspect that others picked it up
> before then. The compiler group had always responded, "not worth the
> test matrix". It also seems that we were the major requestors - it
> seems that our ISVs didn't trust cross-compiling (when it comes to final
> builds, would we?).
> Maybe something has changed, but I don't suspect anything has.
The problem with crosss compilations is that it does not really work if the
software uses dynamic autoconfiguration for portability.
You would first need to hand craft _all_ autoconfiguration results for the
target platform.
Jörg
--
EMail:joerg at schily dot isdn dot cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling at fokus dot fraunhofer dot de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Garrett D'Amore
gdamore@sun.com
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 11, 2008 7:49 AM
in response to: joerg
|
|
Joerg Schilling wrote:
> Joseph Kowalski <jek3 at sun dot com> wrote:
>
>
>> All I can say is "don't hold your breath". I first picked up "this
>> particular torch" in around 1990. I suspect that others picked it up
>> before then. The compiler group had always responded, "not worth the
>> test matrix". It also seems that we were the major requestors - it
>> seems that our ISVs didn't trust cross-compiling (when it comes to final
>> builds, would we?).
>> Maybe something has changed, but I don't suspect anything has.
>>
>
> The problem with crosss compilations is that it does not really work if the
> software uses dynamic autoconfiguration for portability.
>
> You would first need to hand craft _all_ autoconfiguration results for the
> target platform.
>
Most of ON is not autoconfigured. The only exceptions I can think of
would likely be related to 3rd party software (perl?)
Certainly NetBSD has found solutions to this problem. :-)
I wouldn't mind putting some of the 3rd party software that depends on
such autoconfiguration out of ON. I tend to believe that we have a
bunch of stuff in ON, that probably should live in another
consolidation. (Again, perl comes to mind... though I'm sure others
have different, and perhaps equally, or more so, valid opinions.)
-- Garrett
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
3,783
From:
DE
Registered:
4/27/05
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 12, 2008 3:45 AM
in response to: Garrett D'Amore
|
|
"Garrett D'Amore" <gdamore at sun dot com> wrote:
> Most of ON is not autoconfigured. The only exceptions I can think of
> would likely be related to 3rd party software (perl?)
>
> Certainly NetBSD has found solutions to this problem. :-)
>
> I wouldn't mind putting some of the 3rd party software that depends on
> such autoconfiguration out of ON. I tend to believe that we have a
> bunch of stuff in ON, that probably should live in another
> consolidation. (Again, perl comes to mind... though I'm sure others
> have different, and perhaps equally, or more so, valid opinions.)
I believe this is off topic and does not belong into PSARC.
Perl may not belong into ON, but there is other software (currently from
other consolidations) that logically belong into ON.
ON should be self-contained and complete enough to be used in GUI-less
embedded systems. It should only contain software with a free enough license
for embedded usage.
Jörg
--
EMail:joerg at schily dot isdn dot cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling at fokus dot fraunhofer dot de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
3,422
From:
Austin, TX, USA
Registered:
6/15/05
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 11, 2008 7:54 AM
in response to: joerg
|
|
On Tue, Mar 11, 2008 at 03:24:13PM +0100, Joerg Schilling wrote:
> Joseph Kowalski <jek3 at sun dot com> wrote:
>
> > All I can say is "don't hold your breath". I first picked up "this
> > particular torch" in around 1990. I suspect that others picked it up
> > before then. The compiler group had always responded, "not worth the
> > test matrix". It also seems that we were the major requestors - it
> > seems that our ISVs didn't trust cross-compiling (when it comes to final
> > builds, would we?).
> > Maybe something has changed, but I don't suspect anything has.
>
> The problem with crosss compilations is that it does not really work if the
> software uses dynamic autoconfiguration for portability.
That doesn't make cross-compilation useless.
> You would first need to hand craft _all_ autoconfiguration results for the
> target platform.
Not in the ON consolidation, for example, but yes in SFW (which really
means that SFW might well never cross-build).
This case will help third parties who want to cross-build using GCC but
cross-link with the Solaris linker. So there are worthy use cases, even
though they won't generalize to all developers. If we can also leverage
this in any OpenSolaris consolidations, all the better, and if not, oh
well.
Nico
--
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
3,783
From:
DE
Registered:
4/27/05
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 12, 2008 3:24 AM
in response to: nico
|
|
Nicolas Williams <Nicolas dot Williams at sun dot com> wrote:
> On Tue, Mar 11, 2008 at 03:24:13PM +0100, Joerg Schilling wrote:
> > The problem with crosss compilations is that it does not really work if the
> > software uses dynamic autoconfiguration for portability.
>
> That doesn't make cross-compilation useless.
I don't like to say this, but it makes cross compilation harder than people may
expect. Many people believe that cross compilation is easy because the GNU
autoconf documentation incorrectly claims this is something that works by
default. In fact, GNU autoconf provides some basic fallback definitions that
apply for Linux and that may allow to compile a piece of software on a different
Linux platform. If you like or need to go beyond this, you start hand crafting
the "autoconf results".
> > You would first need to hand craft _all_ autoconfiguration results for the
> > target platform.
>
> Not in the ON consolidation, for example, but yes in SFW (which really
> means that SFW might well never cross-build).
This is no longer true for ON since ON contains ksh93 and if more software that
uses dynamic configuration is added to ON, things become even harder.
Note that you cannot create a non-portable (static) variants from ksh93, star,
cdrtools, ... for Solaris because nobody would pay for this unneeded fork.
In order to avoid confusion: ksh93 creates static include files for the ISAs
that are already supported in native compile mode. New platforms need new
include files.
> This case will help third parties who want to cross-build using GCC but
> cross-link with the Solaris linker. So there are worthy use cases, even
> though they won't generalize to all developers. If we can also leverage
> this in any OpenSolaris consolidations, all the better, and if not, oh
> well.
It is worth to do (in special as the GNU ld also does it) but the pitfalls
should be documented.
Jörg
--
EMail:joerg at schily dot isdn dot cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling at fokus dot fraunhofer dot de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 12, 2008 3:50 AM
in response to: joerg
|
|
>Nicolas Williams <Nicolas dot Williams at sun dot com> wrote:
>
>> On Tue, Mar 11, 2008 at 03:24:13PM +0100, Joerg Schilling wrote:
>
>> > The problem with crosss compilations is that it does not really work if the
>> > software uses dynamic autoconfiguration for portability.
>>
>> That doesn't make cross-compilation useless.
>
>I don't like to say this, but it makes cross compilation harder than people may
>expect. Many people believe that cross compilation is easy because the GNU
>autoconf documentation incorrectly claims this is something that works by
>default. In fact, GNU autoconf provides some basic fallback definitions that
>apply for Linux and that may allow to compile a piece of software on a different
>Linux platform. If you like or need to go beyond this, you start hand crafting
>the "autoconf results".
For Solaris we generally do not use auto configuration; this includes even
things like perl.
Certainly the bits which are used initial bringup do not depend on auto
configuration; that may change if ksh93 becomes more important but if
cross-compiling for architecture ports becomes a requirement for ON, then
something will have to give.
But that's neither here nor this case.
Casper
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
5,504
From:
US
Registered:
3/9/05
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 12, 2008 7:41 AM
in response to: casper
|
|
Casper.***@Sun.COM wrote:
> For Solaris we generally do not use auto configuration; this includes even
> things like perl.
s/Solaris/ON/ - there's a lot of autoconfiguration in the rest of Solaris -
X, JDS, SFW - probably more software is autoconfigured there than delivered
by all of ON.
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 12, 2008 7:53 AM
in response to: alanc
|
|
>Casper.***@Sun.COM wrote:
>> For Solaris we generally do not use auto configuration; this includes even
>> things like perl.
>
>s/Solaris/ON/ - there's a lot of autoconfiguration in the rest of Solaris -
>X, JDS, SFW - probably more software is autoconfigured there than delivered
>by all of ON.
For bootstrapping an "Emerging Platform", there's no need to even attempt
to compile everything, right?
Cross-compile that what you minimally need to start running the rest;
that may even be less than ON.
Casper
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Joseph Kowalski
jek3@sun.com
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 11, 2008 1:25 PM
in response to: joerg
|
|
Joerg Schilling wrote:
> Joseph Kowalski <jek3 at sun dot com> wrote:
>
>
>> All I can say is "don't hold your breath". I first picked up "this
>> particular torch" in around 1990. I suspect that others picked it up
>> before then. The compiler group had always responded, "not worth the
>> test matrix". It also seems that we were the major requestors - it
>> seems that our ISVs didn't trust cross-compiling (when it comes to final
>> builds, would we?).
>> Maybe something has changed, but I don't suspect anything has.
>>
>
> The problem with crosss compilations is that it does not really work if the
> software uses dynamic autoconfiguration for portability.
>
> You would first need to hand craft _all_ autoconfiguration results for the
> target platform.
>
> Jörg
>
Speaking of style, its rather interesting to not make it clear that you
are agreeing with
me, or adding another supporting fact.
Anyway, yes, autoconfiguration needs to be considered.
- jek3
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Joseph Kowalski
jek3@sun.com
|
|
|
|
Re: PSARC/2008/179 cross link-editor
Posted:
Mar 6, 2008 12:25 PM
in response to: Garrett D'Amore
|
|
Garrett D'Amore wrote:
>
> Ali,
>
> Thanks for the clarification and your comments, not to mention your
> efforts here!
>
> I certainly hope the compiler group will pick up this particular
> torch. The utility of being able to cross-compile just seems too
> compelling to ignore. (Heck, they'd probably like to be able to
> cross-compile their own tool chain -- I gotta think that waiting
> around for SPARC builds when much faster or cheaper x86 hardware is
> readily obtainable is something that they'd like to avoid.
Maybe we should just move all of our C code to Java... Then we wouldn't
even have to do multiple compilations.
Did I *really* say that? :-)
- jek3
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
