Jonathan Adams <[EMAIL PROTECTED]> wrote:
> > It is strange, the cc -flags output suggest that
> >
> > cc -YP,/usr/libdir
> >
> > should work but it seems that ld(1) does not know about this.
>
> Works for me:
>
> % cc -YP,/foo -o tmpc tmpc.c
> ld: fatal: library -lc: not found
> ld: fatal: Fil
On Mon, Aug 14, 2006 at 02:41:52PM +0200, Joerg Schilling wrote:
> Jonathan Adams <[EMAIL PROTECTED]> wrote:
>
> > > > -YI,/path/to/replacement/for/usr/include
> > > >
> > > > I've done some of the work for this; I'll see if I can drag out my
> > > > e-mails
> > > > from a year ago that list all
On Sat, Aug 12, 2006 at 11:40:20PM +0200, Joerg Schilling wrote:
> Gavin Maltby <[EMAIL PROTECTED]> wrote:
>
> > Joerg Schilling wrote:
> >
> > >
> > > This would make OpenSolaris more stable even in the non-cross compilation
> > > case. Note that OpenSolaris does use /usr/include from the host s
Jonathan Adams <[EMAIL PROTECTED]> wrote:
> > > -YI,/path/to/replacement/for/usr/include
> > >
> > > I've done some of the work for this; I'll see if I can drag out my
> > > e-mails
> > > from a year ago that list all of the wonderful corners.
> > >
> > > IIRC, if we can ignore C++ and assembly,
The problem was getting an alternate /usr/lib to ld(1); it's probably possible
to do, but the GCC setup when I was doing it made it annoying.
Try adding "-Wl,-rpath-link,$(ROOT)/lib:$(ROOT)/usr/lib" or similar to
the LDFLAGS That's what we use to cross compile our app. for NetBSD
on sol
Gavin Maltby <[EMAIL PROTECTED]> wrote:
> Joerg Schilling wrote:
>
> >
> > This would make OpenSolaris more stable even in the non-cross compilation
> > case. Note that OpenSolaris does use /usr/include from the host system
> > instead
> > of using the include files that are specific to the cur
Alan DuBoff wrote:
> On Friday 11 August 2006 11:23 am, Garrett D'Amore wrote:
>
>> Gcc can definitely be made to work. :-) I've been using cross-compile
>> environments with GCC to cross compile whole NetBSD distributions for
>> MIPS using a build environment running on my Sun Ultra 20 (runnin
On Friday 11 August 2006 11:23 am, Garrett D'Amore wrote:
> Gcc can definitely be made to work. :-) I've been using cross-compile
> environments with GCC to cross compile whole NetBSD distributions for
> MIPS using a build environment running on my Sun Ultra 20 (running
> Solaris 10). :-)
GCC wa
On Fri, Aug 11, 2006 at 11:23:40AM -0700, Garrett D'Amore wrote:
> Jonathan Adams wrote:
> > On Fri, Aug 11, 2006 at 10:30:18AM -0700, Gavin Maltby wrote:
> >
> >> Joerg Schilling wrote:
> >>
> >>
> >>> This would make OpenSolaris more stable even in the non-cross compilation
> >>> case. No
Garrett D'Amore wrote:
Has anyone given any thought to convincing OpenSolaris to use its own
proto area (populated by the install_h target or somesuch) instead of
assuming local system headers?
What about libraries? Startup code? Tools?
I have s story of a brute-force approach to a related
Jonathan Adams wrote:
> On Fri, Aug 11, 2006 at 10:30:18AM -0700, Gavin Maltby wrote:
>
>> Joerg Schilling wrote:
>>
>>
>>> This would make OpenSolaris more stable even in the non-cross compilation
>>> case. Note that OpenSolaris does use /usr/include from the host system
>>> instead of us
On Fri, Aug 11, 2006 at 02:00:16PM -0400, Richard Lowe wrote:
> Gavin Maltby wrote:
> >Joerg Schilling wrote:
> >
> >>
> >>This would make OpenSolaris more stable even in the non-cross compilation
> >>case. Note that OpenSolaris does use /usr/include from the host system
> >>instead of using the i
Gavin Maltby wrote:
Joerg Schilling wrote:
This would make OpenSolaris more stable even in the non-cross compilation
case. Note that OpenSolaris does use /usr/include from the host system
instead of using the include files that are specific to the current build
Where that happens for ON it
On Fri, Aug 11, 2006 at 10:30:18AM -0700, Gavin Maltby wrote:
> Joerg Schilling wrote:
>
> >
> >This would make OpenSolaris more stable even in the non-cross compilation
> >case. Note that OpenSolaris does use /usr/include from the host system
> >instead of using the include files that are specif
Joerg Schilling wrote:
This would make OpenSolaris more stable even in the non-cross compilation
case. Note that OpenSolaris does use /usr/include from the host system instead
of using the include files that are specific to the current build
Where that happens for ON it is a bug either in ma
> Well, if the interfaces are stable, then maybe the _headers_ can be
> placed into ON to facilitate this kind of building.
Ick. If the interfaces are stable, the build system's headers should
suffice. Pulling everything into ON is not a tractable approach.
(Why stop there? Why not put the c
Peter Memishian wrote:
> > In my opinion, if a library is required to build ON, then it should
> > probably be moved into ON.
>
> Why? If reasonable software engineering practices have been followed, any
> dependencies that ON might have on external libraries should be through
> versioned, stabl
> In my opinion, if a library is required to build ON, then it should
> probably be moved into ON.
Why? If reasonable software engineering practices have been followed, any
dependencies that ON might have on external libraries should be through
versioned, stable interfaces. If external depend
> Well, the kernel and most (if not all) of lib already has ISA-specific
> build directories. Some things in cmd are structured that way, too, but
> an awful lot of stuff just dumps all the derived files into the same
> directory as the sources.
For the curious: commands only have that Mak
> "GD" == Garrett D'Amore <[EMAIL PROTECTED]> writes:
GD> Why so much for cmd?
Well, the kernel and most (if not all) of lib already has ISA-specific
build directories. Some things in cmd are structured that way, too, but
an awful lot of stuff just dumps all the derived files into the same
On Thu, Aug 10, 2006 at 01:08:10PM -0700, Garrett D'Amore wrote:
> >
> > Agreed. If you're interested in working on this, I can put together my
> > notes
> > from the last time I worked on this (a few months back; my first big push
> > was a year or so ago).
> >
>
> Sure. I want to at least
Jonathan Adams wrote:
> On Wed, Aug 09, 2006 at 06:21:38PM -0700, Garrett D'Amore wrote:
>
>
>
Hmm... apart the compilers themselves, what does ON depend on other than
itself? Depending on headers from other consolidations seems "weird".
(We had some ca
On Wed, Aug 09, 2006 at 06:21:38PM -0700, Garrett D'Amore wrote:
> >>>
> >> Hmm... apart the compilers themselves, what does ON depend on other than
> >> itself? Depending on headers from other consolidations seems "weird".
> >> (We had some cases of something like that with shared interfa
On Thu, Aug 10, 2006 at 07:22:41AM -0700, Garrett D'Amore wrote:
> In my opinion, if a library is required to build ON, then it should
> probably be moved into ON.
>
> This might mean that libxml should be moved.
Yes, and most people I've talked with about this have agreed. There
have been at v
Rainer Orth wrote:
[EMAIL PROTECTED] writes:
... which would be a nightmare if you regularly had to build them from
source just to be able to build ON. SFW alone takes about as long to
compile as ON, and (unlike ON) requires a 64-bit machine to build.
When we started with the Solaris 64 bit b
Garrett D'Amore writes:
> In my opinion, if a library is required to build ON, then it should
> probably be moved into ON.
>
> This might mean that libxml should be moved.
>
> If it were moved, then the autoconf code could be removed and replaced
> with hardcoded Makefiles. It probably wouldn't
Rainer Orth wrote:
> [EMAIL PROTECTED] writes:
>
>
>>> ... which would be a nightmare if you regularly had to build them from
>>> source just to be able to build ON. SFW alone takes about as long to
>>> compile as ON, and (unlike ON) requires a 64-bit machine to build.
>>>
>> When we sta
Rainer Orth <[EMAIL PROTECTED]> wrote:
> Unfortunately, fixing this (CR 6401063) is hard since in general autoconf
> tests require that test binaries can run on the build machine. Everything
> else is handled as cross-compilation, which isn't well supported by most
> packages. I've done a couple
[EMAIL PROTECTED] wrote:
>> This list certainly isn't complete, but gives an idea. So overall it's
>> quite a list from the SFW and Admin consolidations.
>>
>
> This doesn't look easy to fix other than by requiring multiple
> consolidations to be installed.
>
> Casper
>
I've always wonder
Rainer Orth <[EMAIL PROTECTED]> wrote:
>
> ... which would be a nightmare if you regularly had to build them from
> source just to be able to build ON. SFW alone takes about as long to
> compile as ON, and (unlike ON) requires a 64-bit machine to build.
This is the pitfall of dynamic auto-config
"Garrett D'Amore" <[EMAIL PROTECTED]> wrote:
> Is there anyone else interested in being able to cross-compile Solaris
> like this? I'm willing to work on an effort to make this work if others
> are interested (and particularly if someone from inside Sun is willing
> to work with me on the process
[EMAIL PROTECTED] writes:
> >... which would be a nightmare if you regularly had to build them from
> >source just to be able to build ON. SFW alone takes about as long to
> >compile as ON, and (unlike ON) requires a 64-bit machine to build.
>
> When we started with the Solaris 64 bit builds, yo
>[EMAIL PROTECTED] writes:
>
>> >This list certainly isn't complete, but gives an idea. So overall it's
>> >quite a list from the SFW and Admin consolidations.
>>
>> This doesn't look easy to fix other than by requiring multiple
>> consolidations to be installed.
>
>... which would be a nightmar
[EMAIL PROTECTED] writes:
> >This list certainly isn't complete, but gives an idea. So overall it's
> >quite a list from the SFW and Admin consolidations.
>
> This doesn't look easy to fix other than by requiring multiple
> consolidations to be installed.
... which would be a nightmare if you r
>This list certainly isn't complete, but gives an idea. So overall it's
>quite a list from the SFW and Admin consolidations.
This doesn't look easy to fix other than by requiring multiple
consolidations to be installed.
Casper
___
opensolaris-code mai
[EMAIL PROTECTED] writes:
> There are, however, a few exceptions: bits not in "ON" and some
> other bits used by the compiler:
>
> - XML and other libraries
> - linker
I initially observed a couple of additional dependencies when I started
building ON without having SUNWCXall install
>OpenSolaris currently requires that you build it on a version of Solaris
>that is very close to the version that you are building. E.g. you can't
>build OpenSolaris on Solaris 9 (or even early releases of Solaris 10.)
>
>I believe that the primary reason for this is differences in system
>header
Garrett D'Amore wrote:
I -know- ARC review is required for interface changes, but I would have
thought there would have to have been some wider review of a major
change like what I'm proposing. Somehow it just sounds "too easy". :-)
It might help to remember that there are two distinct types o
> > Note that my original interest in this was twofold: to simplify ON's
> > Makefiles so that we don't have to track cross-library dependencies, and
> > to allow full parallelism during builds of usr/src/lib.
>
> Those are both likely to be very, very nice benefits. It deserves more
> inv
Mike Kupfer wrote:
>> "GD" == Garrett D'Amore <[EMAIL PROTECTED]> writes:
>>
>
> GD> Is there anyone else interested in being able to cross-compile
> GD> Solaris like this?
>
> I'm interested, and I'm sure others are. But I expect it to be a lot of
> work, particularly for c
Peter Memishian wrote:
> > If I remember correctly Peter Memishian has looked at this a little and
> > came up with the idea of first building "stuff" libraries based on the
> > linker mapfiles on a first pass. The build would then run as normal and
> > use the proto area stub libs.
>
> Rig
> If I remember correctly Peter Memishian has looked at this a little and
> came up with the idea of first building "stuff" libraries based on the
> linker mapfiles on a first pass. The build would then run as normal and
> use the proto area stub libs.
Right. I think Jonathan explored th
> "GD" == Garrett D'Amore <[EMAIL PROTECTED]> writes:
GD> Is there anyone else interested in being able to cross-compile
GD> Solaris like this?
I'm interested, and I'm sure others are. But I expect it to be a lot of
work, particularly for cmd, and I can't justify to myself spending time
on
Jonathan Adams wrote:
> On Wed, Aug 09, 2006 at 05:37:49PM -0700, Garrett D'Amore wrote:
>
>> Darren J Moffat wrote:
>>
>>> Garrett D'Amore wrote:
>>>
OpenSolaris currently requires that you build it on a version of Solaris
that is very close to the version that you are bui
On Wed, Aug 09, 2006 at 05:37:49PM -0700, Garrett D'Amore wrote:
> Darren J Moffat wrote:
> > Garrett D'Amore wrote:
> >> OpenSolaris currently requires that you build it on a version of Solaris
> >> that is very close to the version that you are building. E.g. you can't
> >> build OpenSolaris on
Darren J Moffat wrote:
> Garrett D'Amore wrote:
>> OpenSolaris currently requires that you build it on a version of Solaris
>> that is very close to the version that you are building. E.g. you can't
>> build OpenSolaris on Solaris 9 (or even early releases of Solaris 10.)
>
> Lets nit pick on some
Garrett D'Amore wrote:
OpenSolaris currently requires that you build it on a version of Solaris
that is very close to the version that you are building. E.g. you can't
build OpenSolaris on Solaris 9 (or even early releases of Solaris 10.)
Lets nit pick on some important terminology first :-)
OpenSolaris currently requires that you build it on a version of Solaris
that is very close to the version that you are building. E.g. you can't
build OpenSolaris on Solaris 9 (or even early releases of Solaris 10.)
I believe that the primary reason for this is differences in system
headers and l
48 matches
Mail list logo
