Sign up to maintain packages here
Philip Brown
freeware packages for solaris, vaguely similar to the Debian
concept of having "maintainers" for various software out there.
We are looking for professionally minded people to create quality
packages, within the following guidelines:
1. A person signs up to create and maintain packages of specific free
software. That person is then responsible for making new releases of
their packages, as new versions of the software become available
2. Packages will be created under a new, standard prefix: /opt/csw
(Community SoftWare), with package name of CSWxxx
3. Packages will adhere to certain common standards
4. Packages will be made for both Solaris 8 sparc, and Solaris 8 x86.
(the concept being to alwys support "one back" from "current"
Solaris release)
5. These packages will then be made available for automated download via
pkg-get, at mirror sites around the world.
At this time, we need people who have both sparc and x86 boxes at their
disposal, although in the future, we hope to have shared machines available
for packaging use.
Initially, we want to make sure all packages currently covered by
SFW, will be covered by volunteers. Once the "existing" software is
covered, we will then allow signups for additional software packages.
If you are willing to join the team, sign up at:
http://www.bolthole.com/solaris/CSW/
--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]
S.1618 http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:@@@D
http://www.spamlaws.com/state/ca1.html
Drazen Kacar
> 3. Packages will adhere to certain common standards
Do you have those standards written somewhere?
--
.-. .-. I don't work here. I'm a consultant.
(_ \ / _)
| da...@willfork.com
|
Joe Bloggs
news:slrnaqbn7j....@bolthole.com...
> There is an effort underway to create a community-driven set of
> freeware packages for solaris, vaguely similar to the Debian
> concept of having "maintainers" for various software out there.
Why not just stick with Sun's SFW packages, or the packages on
www.sunfreeware.com ?
Is the reason behind having 'maintainers' to ensure quality + standardized
packages, or is it because the SFW / sunfreeware stuff isn't keeping up with
latest releases?
Philip Brown
>Philip Brown wrote:
>
>> 3. Packages will adhere to certain common standards
>
>Do you have those standards written somewhere?
a work in progress:
http://www.bolthole.com/solaris/CSW/standards.html
Drazen Kacar
> On 10 Oct 2002 20:13:01 GMT, da...@willfork.com wrote:
> >Philip Brown wrote:
> >
> >> 3. Packages will adhere to certain common standards
> >
> >Do you have those standards written somewhere?
>
> a work in progress:
>
> http://www.bolthole.com/solaris/CSW/standards.html
It's a beggining, I suppose. Would you mind adding that all libraries
need to be compiled with -D_REENTRANT?
Joe Bloggs
news:slrnaqbqn...@willfork.com...
> It's a beggining, I suppose. Would you mind adding that all libraries
> need to be compiled with -D_REENTRANT?
And having packages honour the $BASEDIR setting (eg postinstall scripts
append to ${BASEDIR}/etc/inetd.conf rather than just /etc/inetd.conf - lots
of packages, including some SUN-written ones and as a result they don't work
via jumpstart)
And startup scripts really going in /etc/init.d with links from /etc/rc*.d
to this, rather than just popping them straight into /etc/rc*.d. Again,
quite a lot of Sun-written scripts do this.
Philip Brown
>"Philip Brown" <phi...@bolthole.no-bots.com> wrote in message
>news:slrnaqbn7j....@bolthole.com...
>> There is an effort underway to create a community-driven set of
>> freeware packages for solaris, vaguely similar to the Debian
>> concept of having "maintainers" for various software out there.
>
>Why not just stick with Sun's SFW packages, or the packages on
>www.sunfreeware.com ?
As mentioned on the newly created 'standards' proposed page:
"Efforts are focused on providing a greater, more timely set of packages
than SFW, while also having consistency and dependancies that are not
offered by sunfreeware.com"
If sunfreeware.com consistently updated x86 and sparc equally, and also had
package dependancies, there would not be a need.
If SFW had more packages, updated in a timelier fashion, there would not be
a need.
Philip Brown
>"Drazen Kacar" <da...@willfork.com> wrote in message
>news:slrnaqbqn...@willfork.com...
>> It's a beggining, I suppose. Would you mind adding that all libraries
>> need to be compiled with -D_REENTRANT?
>
>And having packages honour the $BASEDIR setting (eg postinstall scripts
>append to ${BASEDIR}/etc/inetd.conf rather than just /etc/inetd.conf - lots
>of packages, including some SUN-written ones and as a result they don't work
>via jumpstart)
>
Good points. I updated the page.
Philip Brown
oops. skipped over this bit:
On Thu, 10 Oct 2002 20:25:21 +0000 (UTC), joebl...@hotmail.com wrote:
>...
>Is the reason behind having 'maintainers' to ensure quality + standardized
>packages, or is it because the SFW / sunfreeware stuff isn't keeping up with
>latest releases?
The reason behind having 'maintainers' is that package maintaince can get
to be a long, tedious business. So there needs to both be specific people
tasked with fixing a problem in a package, and also a distribution of
workload so that one person does not get overwhelmed and not update
packages quickly enough.
[and ideally, quality control, yes. ]
YTC#1
<joebl...@hotmail.com> wrote:
> "Drazen Kacar" <da...@willfork.com> wrote in message
> news:slrnaqbqn...@willfork.com...
>> It's a beggining, I suppose. Would you mind adding that all libraries need to
>> be compiled with -D_REENTRANT?
>
> And having packages honour the $BASEDIR setting (eg postinstall scripts
append
Tell me about it, XIG patch and Lynsoft, both had to be unpiked from my desktop
after applying to a bootdisk image, and of course then sewing into bootdisk
image :=}
<snip>
--
Bruce Porter
XJR1300SP, XJ900F, GSX750W, GS550, GSX250, CB175
POTM#1(KoTL), WUSS#1 , YTC#1(bar), OSOS#2(KoTL) , DS#3 , IbW#18 ,Apostle#8
"The internet is a huge and diverse community
and not every one is friendly"
http://www.ytc1.co.uk
There *is* an alternative! http://www.openoffice.org/
Shao Wu
> On Thu, 10 Oct 2002 21:17:19 +0000 (UTC), joebl...@hotmail.com wrote:
> >"Drazen Kacar" <da...@willfork.com> wrote in message
> >news:slrnaqbqn...@willfork.com...
> >> It's a beggining, I suppose. Would you mind adding that all libraries
> >> need to be compiled with -D_REENTRANT?
> >
> >And having packages honour the $BASEDIR setting (eg postinstall scripts
> >append to ${BASEDIR}/etc/inetd.conf rather than just /etc/inetd.conf - lots
> >of packages, including some SUN-written ones and as a result they don't work
> >via jumpstart)
> >
>
> Good points. I updated the page.
>
I suppose you should use "-mt" instead of -D_REENTRANT.
Shao
Philip Brown
>..
>I suppose you should use "-mt" instead of -D_REENTRANT.
only one compiler that I know of, support -mt.
all compiles support -D_REENTRANT.
Joerg Schilling
Joe Bloggs <joebl...@hotmail.com> wrote:
>"Philip Brown" <phi...@bolthole.no-bots.com> wrote in message
>news:slrnaqbn7j....@bolthole.com...
>> There is an effort underway to create a community-driven set of
>> freeware packages for solaris, vaguely similar to the Debian
>> concept of having "maintainers" for various software out there.
>
>Why not just stick with Sun's SFW packages, or the packages on
>www.sunfreeware.com ?
Packages on www.sunfreeware.com are outdated for a long long time.
cdrecord/cdrtools on www.sunfreeware.com is 4 years old!
BTW: www.sunfreeware.com uses javascript :-(
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
Joerg Schilling
>> a work in progress:
>>
>> http://www.bolthole.com/solaris/CSW/standards.html
>
>It's a beggining, I suppose. Would you mind adding that all libraries
>need to be compiled with -D_REENTRANT?
Well, this would help to solve the ___errno() problem but what
if the functions in the lib appear not to be reentrant?
Joerg Schilling
Philip Brown <phi...@bolthole.no-bots.com> wrote:
>>Is the reason behind having 'maintainers' to ensure quality + standardized
>>packages, or is it because the SFW / sunfreeware stuff isn't keeping up with
>>latest releases?
>
>The reason behind having 'maintainers' is that package maintaince can get
>to be a long, tedious business. So there needs to both be specific people
This mainly depends on the quality of the upstream packages....
Unfortunately, there are many OSS packages that need many hours of tweaking
around to get them even compiled :-(
If the package maintainer tried to educate the upstream maintainer, this may
save a lot of time in the future (supposed this is possible :-)
Joerg Schilling
Philip Brown <phi...@bolthole.no-bots.com> wrote:
>On Fri, 11 Oct 2002 02:41:05 GMT, sw...@earthlink.net wrote:
>>..
>>I suppose you should use "-mt" instead of -D_REENTRANT.
>
>only one compiler that I know of, support -mt.
>all compiles support -D_REENTRANT.
But there are more differences with -mt:
The on-pass cpp/compiler "acomp" is called with the additional
options:
-D_REENTRANT and -mt
The linker is called with the additional lib -lthread
Jouko Holopainen
> If the package maintainer tried to educate the upstream maintainer, this may
> save a lot of time in the future (supposed this is possible :-)
I have had a couple of times a plan to make a program to generate
pkgadd needed files from rpm package (and Debian deb, of course)
information.
"A plan" is not a very good thing, as there is exactly zero lines of
code, documentation, etc ... :-)
Just to inspire "better" people.
--
@jhol
.net.my.ass
bit-b...@maney.org
: On Thu, 10 Oct 2002 20:25:21 +0000 (UTC), joebl...@hotmail.com wrote:
:>"Philip Brown" <phi...@bolthole.no-bots.com> wrote in message
:>news:slrnaqbn7j....@bolthole.com...
:>> There is an effort underway to create a community-driven set of
:>> freeware packages for solaris, vaguely similar to the Debian
:>> concept of having "maintainers" for various software out there.
:>
:>Why not just stick with Sun's SFW packages, or the packages on
:>www.sunfreeware.com ?
: As mentioned on the newly created 'standards' proposed page:
: "Efforts are focused on providing a greater, more timely set of packages
: than SFW, while also having consistency and dependancies that are not
: offered by sunfreeware.com"
: If sunfreeware.com consistently updated x86 and sparc equally, and also had
: package dependancies, there would not be a need.
: If SFW had more packages, updated in a timelier fashion, there would not be
: a need.
Then why re-invent the wheel? Why not work with sunfreeware.com to
fix the deficiencies and problems that it has?
fpsm
--
| Fredrich P. Maney my_last_name AT my_last_name DOT org |
| Do NOT send me HTML formatted E-mail or copies of netnews posts! |
| Address in header is a spamtrap. Use one in signature for replies. |
| Please review http://www.maney.org/uce/ before emailing. |
Casper H.S. Dik
>In article <slrnaqbqn...@willfork.com>,
>Drazen Kacar <da...@willfork.com> wrote:
>>Philip Brown wrote:
>>> a work in progress:
>>>
>>> http://www.bolthole.com/solaris/CSW/standards.html
>>
>>It's a beggining, I suppose. Would you mind adding that all libraries
>>need to be compiled with -D_REENTRANT?
>Well, this would help to solve the ___errno() problem but what
>if the functions in the lib appear not to be reentrant?
I would allow you to call them from any one thread and do your own locking.
Another issue for binary packages is "C++" code; g++ and Sun's CC use
a different ABI; perhaps C++ libraries should ship in two versions to
be installed at two different locations?
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Barbie LeVile
Casper H.S. Dik <Caspe...@Sun.COM> wrote:
>
> Another issue for binary packages is "C++" code; g++ and Sun's CC use
> a different ABI; perhaps C++ libraries should ship in two versions to
> be installed at two different locations?
>
Not only gcc and forte, but gcc depening on version too
--
Barbie - Prayers are like junkmail for Jesus
I have seen things you lusers would not believe.
I've seen Sun monitors on fire off the side of the multimedia lab.
I've seen NTU lights glitter in the dark near the Mail Gate.
All these things will be lost in time, like the root partition last week.
Time to die.
Drazen Kacar
> But there are more differences with -mt:
>
> The on-pass cpp/compiler "acomp" is called with the additional
> options:
>
> -D_REENTRANT and -mt
>
> The linker is called with the additional lib -lthread
Except when you are building a shared object. Which can cause problems on
Solaris 8 with its two thread libraries. But this might depend on the
compiler version; I'm not sure.
Philip Brown
>In comp.unix.solaris Philip Brown <phi...@bolthole.no-bots.com> wrote:
>: If sunfreeware.com consistently updated x86 and sparc equally, and also had
>: package dependancies, there would not be a need.
>
>: If SFW had more packages, updated in a timelier fashion, there would not be
>: a need.
>
>Then why re-invent the wheel? Why not work with sunfreeware.com to
>fix the deficiencies and problems that it has?
sunfreeware.com is run by one person, Steve Christensen, who does not
allow anyone else to make packages.
The deficiencies have been known for a long time. They have been pointed
out. They have not been fixed.
Drazen Kacar
> j...@cs.tu-berlin.de (Joerg Schilling) writes:
>
> >In article <slrnaqbqn...@willfork.com>,
> >Drazen Kacar <da...@willfork.com> wrote:
> >>It's a beggining, I suppose. Would you mind adding that all libraries
> >>need to be compiled with -D_REENTRANT?
>
> >Well, this would help to solve the ___errno() problem but what
> >if the functions in the lib appear not to be reentrant?
>
> I would allow you to call them from any one thread and do your own locking.
Or no locking at all, if it's used from just one thread which doesn't
happen to be the main one.
> Another issue for binary packages is "C++" code; g++ and Sun's CC use
> a different ABI; perhaps C++ libraries should ship in two versions to
> be installed at two different locations?
An arrangement like that can become rather problematic. You have a bunch
of *-config scripts in use these days and they do not take compiler as an
input argument.
That's the variant of a Perl compiler problem, I suppose.
Drazen Kacar
> On 11 Oct 2002 15:03:12 GMT
> Casper H.S. Dik <Caspe...@Sun.COM> wrote:
> > Another issue for binary packages is "C++" code; g++ and Sun's CC use
> > a different ABI; perhaps C++ libraries should ship in two versions to
> > be installed at two different locations?
>
> Not only gcc and forte, but gcc depening on version too
Forte also depends on version.
John D Groenveld
Haven't seen any problems moving from Workshop 5 to Forte 6u2.
What problems should I be looking out for?
John
groe...@acm.org
Drazen Kacar
No problems between those two versions. You've got incompatibility between
4.2 and later versions, where later versions provide -compat=4 switch, but
you cannot mix the two.
For an in depth discussion, refer to <inst_directory>/READMEs/c++
document; search for "Compiler Version Incompatibilities". I don't know if
that's on-line somewhere.
John D Groenveld
Drazen Kacar <da...@willfork.com> wrote:
>For an in depth discussion, refer to <inst_directory>/READMEs/c++
>document; search for "Compiler Version Incompatibilities". I don't know if
>that's on-line somewhere.
Thanks.
<URL:http://www.sun.com/software/sundev/suncc/documentation/mr/READMEs/c++.html>
John
groe...@acm.org
Oscar del Rio
"Philip Brown" <phi...@bolthole.no-bots.com> wrote
> There is an effort underway to create a community-driven set of
> freeware packages for solaris, vaguely similar to the Debian
> concept of having "maintainers" for various software out there.
Great initiative, thanks!
> 1. A person signs up to create and maintain packages of specific free
> software. That person is then responsible for making new releases of
> their packages, as new versions of the software become available
How "responsible" would the volunteer be for critical security updates?
Say on a long weekend or while on vacation, a security vulnerability
is discovered in openssl (for example) that you volunteered to maintain.
Are you going to be blamed if you do not upgrade the package immediately
or if you are not available for a few days?
Perhaps there should be "teams" of maintainers for some critical packages.
> 4. Packages will be made for both Solaris 8 sparc, and Solaris 8 x86.
> (the concept being to alwys support "one back" from "current"
> Solaris release)
How about hardware? Some sparc builds are dependent on the
architecture (sun4m, sun4u) even if they are for the same Solaris version.
Perhaps there should be support for "one back" from current hardware
platform when possible, and/or the package should not install on the
wrong hardware. That should also prevent new users from installing
sparc packages on x86 or viceversa.
This project sounds promising. I hope an improved community support
would convince Sun and other commercial developers that solaris x86
is worth supporting. (anybody from Mathworks reading?)
Joe Bloggs
> software. That person is then responsible for making new releases of
> their packages, as new versions of the software become available
What's to be published on the community site : just the package, or option
to download the source + pkg build scripts too? The latter sounds better to
me : too much trust gets placed in the package builder otherwise - we've all
seen the recent troubles with trojans sneaking into the sendmail build.
> 4. Packages will be made for both Solaris 8 sparc, and Solaris 8 x86.
> (the concept being to alwys support "one back" from "current"
> Solaris release)
So packages will be for Solaris 8 sparc+x86 and 9 sparc+x86 in the first
instance?
> 5. These packages will then be made available for automated download via
> pkg-get, at mirror sites around the world.
> Initially, we want to make sure all packages currently covered by
> SFW, will be covered by volunteers. Once the "existing" software is
> covered, we will then allow signups for additional software packages.
Perhaps useful if Sun showed some more community spirit and handed over the
package sources + build scripts for all the SFW stuff, so the CSW project
would at least get off to a quick start and none of the transition phase
when some stuff's available on SFW and not yet on CSW ?
Joe
Per Espen Hagen
> bit-b...@maney.org wrote:
> > Philip Brown <phi...@bolthole.no-bots.com> wrote:
> >: If sunfreeware.com consistently updated x86 and sparc equally, and also had
> >: package dependancies, there would not be a need.
> >
> >: If SFW had more packages, updated in a timelier fashion, there would not be
> >: a need.
> >
> >Then why re-invent the wheel? Why not work with sunfreeware.com to
> >fix the deficiencies and problems that it has?
>
> sunfreeware.com is run by one person, Steve Christensen, who does not
> allow anyone else to make packages.
>
> The deficiencies have been known for a long time. They have been pointed
> out. They have not been fixed.
Okay, so why not try to work with Sun? I'm sure they would be happy to
let the community take over the responsibility for /opt/sfw. Some of the
benefits would be:
1. It would give the project a flying start -- loads of useful packages
already exist. Some may be a bit outdated, but many are not.
2. /opt/sfw has just been established as the new place for apps to look
for libraries -- and it WILL NOT GO AWAY unless Sun decides to drop it
as the official Solaris OSS directory.
3. Going for /opt/csw means that third-party software developers will
have to look THREE places for e.g. libgtk -- /usr/local/lib (the default
location for all locally built stuff, and unfortunately also the
SunFreeware install location), /opt/sfw/lib (the official location of
OSS software, as set forth by Sun), and /opt/csw/lib. Dependency
checking will be pretty much impossible -- a package would have to check
for either SMCgtk, SFWgtk, or CSWgtk.
If you'll go for /opt/sfw, I wouldn't mind joining the effort and moving
my packages (http://espen.s5.com/) to this system. (My packages already
install to /opt/sfw, and some of them (like SDL) are updated
replacements for Sun's SFW packages. I just don't use the SFW prefix.)
We do have a bunch of SPARC boxes standing around, so I wouldn't have
any problem building my stuff for SPARC either (except that some of the
packages on my site contain x86 assembly, and so can't be built for
SPARC without a major rewrite.)
If Sun, for some unfathomable reason, don't want the community to take
over or collaborate with them on /opt/sfw, you can *still* install to
/opt/sfw, and you can *still* name the packages SFWwhatever. They will
still be "compatible" with the Software Companion packages -- they just
won't be officially sanctioned by Sun. Which is exactly the case if you
bypass Sun entirely and go for /opt/csw. So what is there to lose by
doing it that way?
--
¤º°`°º¤ø,¸¸,ø¤º°`°º¤øø¤º°`°º¤ø,¸¸,ø¤º°`°º¤
Per Espen Hagen, Principal Scientist
Norwegian Defence Research Establishment
Drazen Kacar
> Okay, so why not try to work with Sun? I'm sure they would be happy to
> let the community take over the responsibility for /opt/sfw. Some of the
> benefits would be:
I don't see how to resolve security issues. If Sun ships some binary
packages, Sun is responsible for them. Why would Sun trust community
maintainers?
> 2. /opt/sfw has just been established as the new place for apps to look
> for libraries
In some circles, perhaps.
> -- and it WILL NOT GO AWAY unless Sun decides to drop it
> as the official Solaris OSS directory.
Probably.
> 3. Going for /opt/csw means that third-party software developers will
> have to look THREE places for e.g. libgtk -- /usr/local/lib (the default
> location for all locally built stuff, and unfortunately also the
> SunFreeware install location), /opt/sfw/lib (the official location of
> OSS software, as set forth by Sun), and /opt/csw/lib. Dependency
> checking will be pretty much impossible -- a package would have to check
> for either SMCgtk, SFWgtk, or CSWgtk.
It already is impossible. How is your binary package built on Solaris 2.6
supposed to know about Sun's libz or libXpm in Solaris 9? I'm not SVR4
packaging expert, but from what I remember, there is no way to depend on
this package or that package, even if you knew the names. And there's no
way to define virtual packages.
But the real fuck up happens if anyone other than Sun decides to use
internal library versioning.
By the by, none of those three packages (CSWgtk is hypotetical, but I'm
assuming it would be produced just like the rest of GTK+ packages one can
find on the net) would be able to run some of my GTK binaries.
> If Sun, for some unfathomable reason, don't want the community to take
> over or collaborate with them on /opt/sfw, you can *still* install to
> /opt/sfw, and you can *still* name the packages SFWwhatever. They will
> still be "compatible" with the Software Companion packages -- they just
> won't be officially sanctioned by Sun.
Are you sure you understand what compatibility on the binary level means?
There are linker options you'd have to reproduce exactly. The information
you'd need can be gathered from the binary objects, but I don't see the
point in performing this kind of reverse engineering.
> Which is exactly the case if you bypass Sun entirely and go for
> /opt/csw. So what is there to lose by doing it that way?
You don't get to see unpleasant surprises. You don't stomp on somebody
else's namespace, so somebody else won't hate you with a passion.
Per Espen Hagen
> > 5. These packages will then be made available for automated download via
> > pkg-get, at mirror sites around the world.
>
> > Initially, we want to make sure all packages currently covered by
> > SFW, will be covered by volunteers. Once the "existing" software is
> > covered, we will then allow signups for additional software packages.
>
> Perhaps useful if Sun showed some more community spirit and handed over the
> package sources + build scripts for all the SFW stuff, so the CSW project
> would at least get off to a quick start and none of the transition phase
> when some stuff's available on SFW and not yet on CSW ?
Or, as I suggested in another message in this thread: Why is there a
need to transition from SFWpkg and /opt/sfw to CSWpkg and /opt/csw in
the first place? Even if Sun doesn't want the community to help them
keep the SFW stuff up to date, we can still do it.
If Sun at some point discontinues SFW and lets CSW be the norm, little
will be gained, and everybody who installed the Software Companion CD
that ships with Solaris will have to get everything from CSW and install
it all over again. A lot of work for eveyone, just because of a
pointless name change.
If Sun continues to ship outdated SFW stuff, the situation will be even
worse. Users will get SFW with Solaris, but the community will tell them
to "throw away that CD, download everything from our site instead". Many
people still prefer a CD to a 650 MB download, and will ignore that
request.
I just can't see *any* good reasons for creating yet another location
and package name. SFW was a great idea, it was sanctioned and supported
by Sun, and I don't see why people want to add yet another layer of
confusion -- SFW won't go away until Sun decides to drop it.
Sun doesn't hold a copyright on the "SFW" abbreviation or the /opt/sfw
directory name. Anyone can build a package that installs to /opt/sfw,
and name it SFWfoo. What's stopping us from doing it that way?
Barbie LeVile
Per Espen Hagen <es...@hagen.cc> wrote:
> If you'll go for /opt/sfw, I wouldn't mind joining the effort and moving
> my packages (http://espen.s5.com/) to this system. (My packages already
> install to /opt/sfw, and some of them (like SDL) are updated
hrm, i noticed the sac program, is there any change to get the source to
compile it on sparc?
i was looking for something like that for ages to replace the
sdtaudiocontrol from sun
Per Espen Hagen
> Per Espen Hagen wrote:
>
> > Okay, so why not try to work with Sun? I'm sure they would be happy to
> > let the community take over the responsibility for /opt/sfw. Some of the
> > benefits would be:
>
> I don't see how to resolve security issues. If Sun ships some binary
> packages, Sun is responsible for them. Why would Sun trust community
> maintainers?
IIRC, the SFW packages come with a long disclaimer stating that they are
wholly unsupported by Sun. Sun does not assume any responsbility for the
SFW packages.
Of course, the preferred solution would be if Sun wanted to "work with
the community" as they always say they will. How about something like
this:
The community maintainer downloads and builds a new version of package
foo, checks that it works (or performs whatever modifications
necessary), and mails the original source URL and any options or diffs
needed to the Sun coordinator, who downloads the original source
himself, builds it, packages it, and releases it to the SFW master ftp
site. If the latter process turns out to be slow, the maintainer can
upload the package himself to an "SFW-untrusted" ftp site.
Some simple scripts and guidelines could be made. The process at Sun
could be close to automatic (basically, just go through any diffs to see
if they can be malicious).
If we're not working with Sun on this, all we will have is the
"untrusted" sites, so nothing will be gained in this respect.
> > 3. Going for /opt/csw means that third-party software developers will
> > have to look THREE places for e.g. libgtk -- /usr/local/lib (the default
> > location for all locally built stuff, and unfortunately also the
> > SunFreeware install location), /opt/sfw/lib (the official location of
> > OSS software, as set forth by Sun), and /opt/csw/lib. Dependency
> > checking will be pretty much impossible -- a package would have to check
> > for either SMCgtk, SFWgtk, or CSWgtk.
>
> It already is impossible. How is your binary package built on Solaris 2.6
> supposed to know about Sun's libz or libXpm in Solaris 9? I'm not SVR4
> packaging expert, but from what I remember, there is no way to depend on
> this package or that package, even if you knew the names. And there's no
> way to define virtual packages.
Phil's suggestion was to support only Solaris 8 and 9 (if necessary,
with separate packages for 8 and 9 even).
My point is, if most people agree that the GTK package is called SFWgtk,
package dependencies will work -- for most people. And IIRC, you are
allowed to install a package even if dependency checking fails. If the
Solaris user community splits up into an SFW camp (including Sun itself)
and a CSW camp, third party developers can just forget about dependency
checking for their packages.
> By the by, none of those three packages (CSWgtk is hypotetical, but I'm
> assuming it would be produced just like the rest of GTK+ packages one can
> find on the net) would be able to run some of my GTK binaries.
That's irrelevant -- as you assume that the hypothetical community
CSWgtk wouldn't work for you, it really doesn't matter what the package
is called or where it installs to. If you have that kind of specific
needs, you would have to build your own GTK library anyway.
> > If Sun, for some unfathomable reason, don't want the community to take
> > over or collaborate with them on /opt/sfw, you can *still* install to
> > /opt/sfw, and you can *still* name the packages SFWwhatever. They will
> > still be "compatible" with the Software Companion packages -- they just
> > won't be officially sanctioned by Sun.
>
> Are you sure you understand what compatibility on the binary level means?
> There are linker options you'd have to reproduce exactly. The information
> you'd need can be gathered from the binary objects, but I don't see the
> point in performing this kind of reverse engineering.
I've built dozens of packages that depend on Sun's SFW packages, they
have probably been installed on thousands of systems, and noone has ever
reported any compatibility problems to me.
Yes, there are problems with replacing e.g. shared libraries that use
C++. Sure. But this is a small minority of the packages. When building
*applications*, they will either build or fail to build, and work or
fail to work.
I'm not saying it's trivial. There are all sorts of problems with
creating a large group of consistent packages that depend on other
packages etc. Different apps can require different versions of libraries
etc. etc. I just don't think the added problems with building on SFW add
that much to this.
Again, the best thing would of course be if Sun would work with the
community on this. Has Phil or anyone else even tried to approach Sun on
this?
> > Which is exactly the case if you bypass Sun entirely and go for
> > /opt/csw. So what is there to lose by doing it that way?
>
> You don't get to see unpleasant surprises. You don't stomp on somebody
> else's namespace, so somebody else won't hate you with a passion.
Sun appears to have all but abandoned their SFW effort (at least keeping
it up to date), so I doubt they will hate anyone who picks it up. But
again -- how about asking them first?
Per Espen Hagen
>
> On Sat, 12 Oct 2002 08:19:14 GMT
> Per Espen Hagen <es...@hagen.cc> wrote:
>
> > If you'll go for /opt/sfw, I wouldn't mind joining the effort and moving
> > my packages (http://espen.s5.com/) to this system. (My packages already
> > install to /opt/sfw, and some of them (like SDL) are updated
>
> hrm, i noticed the sac program, is there any change to get the source to
> compile it on sparc?
Okay, I've put up the source code now. I don't remember where I got it
in the first place, but there are two email addresses in the README file
(I won't put the poor guy's email address on Usenet... you'll have to
download and unzip the source.)
> i was looking for something like that for ages to replace the
> sdtaudiocontrol from sun
Neither the author nor I have tried to compile or run SAC on sparc. The
audio API isn't 100% identical, but will probably work.
Drazen Kacar
> Drazen Kacar wrote:
> > Per Espen Hagen wrote:
> >
> > > Okay, so why not try to work with Sun? I'm sure they would be happy to
> > > let the community take over the responsibility for /opt/sfw. Some of the
> > > benefits would be:
> >
> > I don't see how to resolve security issues. If Sun ships some binary
> > packages, Sun is responsible for them. Why would Sun trust community
> > maintainers?
>
> IIRC, the SFW packages come with a long disclaimer stating that they are
> wholly unsupported by Sun. Sun does not assume any responsbility for the
> SFW packages.
Void where prohibited. Aside from that, long disclaimer won't have any
effect in case of BugTraq audience.
> Of course, the preferred solution would be if Sun wanted to "work with
> the community" as they always say they will. How about something like
> this:
>
> The community maintainer downloads and builds a new version of package
> foo, checks that it works (or performs whatever modifications
> necessary), and mails the original source URL and any options or diffs
> needed to the Sun coordinator, who downloads the original source
> himself, builds it, packages it, and releases it to the SFW master ftp
> site. If the latter process turns out to be slow, the maintainer can
> upload the package himself to an "SFW-untrusted" ftp site.
That's fine by me, except that you don't need Sun coordinator at all.
Maybe to get an official blessing, whatever that might mean.
> Some simple scripts and guidelines could be made. The process at Sun
> could be close to automatic (basically, just go through any diffs to see
> if they can be malicious).
You're assuming Sun wants to pay for code reviews. If SFW packages aren't
being regularly updated by people at Sun (I don't really know, but that's
how I understand the discussion so far), what makes you think Sun would
want to invest more time (equals money) into more complicated process?
> > It already is impossible. How is your binary package built on Solaris 2.6
> > supposed to know about Sun's libz or libXpm in Solaris 9? I'm not SVR4
> > packaging expert, but from what I remember, there is no way to depend on
> > this package or that package, even if you knew the names. And there's no
> > way to define virtual packages.
>
> Phil's suggestion was to support only Solaris 8 and 9 (if necessary,
> with separate packages for 8 and 9 even).
OK, then let's take libXpm and libxml2 as examples. That's the difference
between S8 and S9.
> My point is, if most people agree that the GTK package is called SFWgtk,
> package dependencies will work -- for most people.
Sure. Trouble with that scheme is that people for whom it won't work are
usually the ones you'd like to enlist as maintainers.
> And IIRC, you are allowed to install a package even if dependency
> checking fails.
Yep, but I won't. Enterprise policy. :-)
> If the Solaris user community splits up into an SFW camp (including Sun
> itself) and a CSW camp, third party developers can just forget about
> dependency checking for their packages.
The way I usually put it is "The packaging system sucks and needs certain
feature enhancements." I don't expect to see them any time soon, though.
> > By the by, none of those three packages (CSWgtk is hypotetical, but I'm
> > assuming it would be produced just like the rest of GTK+ packages one can
> > find on the net) would be able to run some of my GTK binaries.
>
> That's irrelevant -- as you assume that the hypothetical community
> CSWgtk wouldn't work for you, it really doesn't matter what the package
> is called or where it installs to. If you have that kind of specific
> needs, you would have to build your own GTK library anyway.
Depends on what you'd call specific. All I need is that the binaries are
built in accordance with the platform rules and recommendations. No more,
no less. The default build procedure doesn't produce such binaries, so
some perfectly legal and useful things fail.
> > Are you sure you understand what compatibility on the binary level means?
> > There are linker options you'd have to reproduce exactly. The information
> > you'd need can be gathered from the binary objects, but I don't see the
> > point in performing this kind of reverse engineering.
>
> I've built dozens of packages that depend on Sun's SFW packages, they
> have probably been installed on thousands of systems, and noone has ever
> reported any compatibility problems to me.
"Depend on" and "replace" are two different things. Although I don't
expect you'd have a lot of problems with replacing Sun's SFW packages.
That's because they don't do much more than "./configure; make install".
Packages which go into the supported part of the OS see more care. So, in
the unlikely event that /opt/sfw and /usr/sfw packages see more loving,
you might be forced to follow the suit. Which isn't bad in itself.
> Yes, there are problems with replacing e.g. shared libraries that use
> C++.
Let's leave C++ aside for now.
> Sure. But this is a small minority of the packages. When building
> *applications*, they will either build or fail to build, and work or
> fail to work.
Or fail to work at some unspecified point after start-up. Or fail to work
in some locales, but not all. Or fail to work with some other software,
but not all (window managers, for example). Or fail to work with my paper
size. And small things like that.
> I'm not saying it's trivial. There are all sorts of problems with
> creating a large group of consistent packages that depend on other
> packages etc. Different apps can require different versions of libraries
> etc. etc. I just don't think the added problems with building on SFW add
> that much to this.
There is a large potential problem if you build on top of it without
coordinating with Sun. And that's Sun changing god knows what behind your
back.
> Again, the best thing would of course be if Sun would work with the
> community on this.
Certainly. After all, only Sun can improve the packaging system. :-)
> Sun appears to have all but abandoned their SFW effort (at least keeping
> it up to date), so I doubt they will hate anyone who picks it up.
I would, but I'm not a very nice person, so you should have better luck
with somebody else. :-)
> But again -- how about asking them first?
Sure. Hey, Mike, what's the deal with all this?
Philip Chee
>j...@cs.tu-berlin.de (Joerg Schilling) writes:
>> If the package maintainer tried to educate the upstream maintainer, this may
>> save a lot of time in the future (supposed this is possible :-)
>I have had a couple of times a plan to make a program to generate
>pkgadd needed files from rpm package (and Debian deb, of course)
>information.
A sort of reverse 'alien' then? I propose the term 'chthonian'
Philip
---=====================================================================---
Philip Chee: Tasek Corporation Berhad, P.O.Box 254, 30908 Ipoh, MALAYSIA
e-mail: phi...@aleytys.pc.my Voice:+60.5.291.1011 Fax:+60.5.291.9932
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
--
ž 20506.32 ž Boldly going Forward because we can't find Reverse!
Casper H.S. Dik
>An arrangement like that can become rather problematic. You have a bunch
>of *-config scripts in use these days and they do not take compiler as an
>input argument.
Hm, the typical GNU configure scripts work with
env CC=mycc ./configure
But yes, it is tricky.
Casper H.S. Dik
>Barbie LeVile wrote:
>> On 11 Oct 2002 15:03:12 GMT
>> Casper H.S. Dik <Caspe...@Sun.COM> wrote:
>> > Another issue for binary packages is "C++" code; g++ and Sun's CC use
>> > a different ABI; perhaps C++ libraries should ship in two versions to
>> > be installed at two different locations?
>>
>> Not only gcc and forte, but gcc depening on version too
>Forte also depends on version.
But less so; I think we're now at three different versions:
old Cfront based CC
"version 4"
"current"
And the latest compiler supports the last two output types; perhaps
we should suggest compat=4 unless the code isn't compatible with
the old compiler code generation.
Paul Floyd
>
>Okay, so why not try to work with Sun? I'm sure they would be happy to
>let the community take over the responsibility for /opt/sfw. Some of the
>benefits would be:
[snip]
Though things like this always sound like nice ideas, the lawyers
inevitably put the kibosh on them. Would Sun be willing to take the risk
of legal exposure of someone sneaking in a Trojan (like the recent case
with sendmail).
A bientot
Paul
--
Paul Floyd http://paulf.free.fr (for what it's worth)
What happens if you have lead in your pants as well as lead in your pencil?
Per Espen Hagen
> That's fine by me, except that you don't need Sun coordinator at all.
> Maybe to get an official blessing, whatever that might mean.
The benefit for Sun is that they could distribute an extensive set of
working, up-to-date freeware with Solaris -- like GNU/Linux and *BSD
does -- without having to do all the work themselves. The benefits for
the users are (1) that they get those freeware packages delivered with
Solaris (no need for gigabyte downloads), and (2) that, indeed, the
packages are "officially blessed" by Sun, and there's at least much less
likely that a package is trojaned.
> You're assuming Sun wants to pay for code reviews. If SFW packages aren't
> being regularly updated by people at Sun (I don't really know, but that's
> how I understand the discussion so far), what makes you think Sun would
> want to invest more time (equals money) into more complicated process?
The idea is that it would be a *less* complicated process for Sun. The
community maintainers should normally report any changes needed back to
the original developers. If they're not interested in supporting
Solaris, he'd have to supply a diff to the guy at Sun.
Joe Bloggs
news:3DA7E458...@hagen.cc...
> Joe Bloggs wrote:
> Or, as I suggested in another message in this thread: Why is there a
> need to transition from SFWpkg and /opt/sfw to CSWpkg and /opt/csw in
> the first place? Even if Sun doesn't want the community to help them
> keep the SFW stuff up to date, we can still do it.
>
> If Sun at some point discontinues SFW and lets CSW be the norm, little
> will be gained, and everybody who installed the Software Companion CD
> that ships with Solaris will have to get everything from CSW and install
> it all over again. A lot of work for eveyone, just because of a
> pointless name change.
>
> If Sun continues to ship outdated SFW stuff, the situation will be even
> worse. Users will get SFW with Solaris, but the community will tell them
> to "throw away that CD, download everything from our site instead". Many
> people still prefer a CD to a 650 MB download, and will ignore that
> request.
>
> I just can't see *any* good reasons for creating yet another location
> and package name. SFW was a great idea, it was sanctioned and supported
> by Sun, and I don't see why people want to add yet another layer of
> confusion -- SFW won't go away until Sun decides to drop it.
>
> Sun doesn't hold a copyright on the "SFW" abbreviation or the /opt/sfw
> directory name. Anyone can build a package that installs to /opt/sfw,
> and name it SFWfoo. What's stopping us from doing it that way?
Fair points. Avoids a whole world of pain for the lot of us.
In return for Sun's goodwill in giving the pkg build scripts and the like,
they could ship the latest and greatest CSW packages with their quarterly
Solaris hardware updates.
Barbie LeVile
Per Espen Hagen <es...@hagen.cc> wrote:
>
> Okay, I've put up the source code now. I don't remember where I got it
> in the first place, but there are two email addresses in the README file
> (I won't put the poor guy's email address on Usenet... you'll have to
> download and unzip the source.)
ok, thanks, got the source
>
> > i was looking for something like that for ages to replace the
> > sdtaudiocontrol from sun
>
> Neither the author nor I have tried to compile or run SAC on sparc. The
> audio API isn't 100% identical, but will probably work.
>
doesn't works <sniff>
the gui itself works, but opening the audio device results in an error
Drazen Kacar
> Drazen Kacar <da...@willfork.com> writes:
>
> >An arrangement like that can become rather problematic. You have a bunch
> >of *-config scripts in use these days and they do not take compiler as an
> >input argument.
>
> Hm, the typical GNU configure scripts work with
>
> env CC=mycc ./configure
But that's the configure script. A lot of them will ask *-config scripts
for appropriate linker flags, for example "gtk-config --libs". My
instalation prints:
-L/usr/local/lib -R/usr/local/lib -Wl,-zignore -lgtk -lgdk -lXext -lX11
-lgmodule -lglib -ldl -Wl,-zrecord
I've added -zignore and -zrecord to avoid having binaries record
dependencies on a bunch of libraries which aren't really needed. That will
not work with Sun's CC because it doesn't understand -Wl flag.
Even without those two (which is the default), you have -L flag (and
hopefully the packager will add the corresponding -R flag). Since there is
no way to pass a compiler to gtk-config, it cannot generate different -L
and -R for different compilers.
In this example it's not needed because we're dealing with C libraries
exclusively, but if one of them were C++ library, you'd need different -L
and -R flags.
Drazen Kacar
> Drazen Kacar <da...@willfork.com> writes:
> >Forte also depends on version.
>
> But less so; I think we're now at three different versions:
>
> old Cfront based CC
> "version 4"
> "current"
>
> And the latest compiler supports the last two output types; perhaps
> we should suggest compat=4 unless the code isn't compatible with
> the old compiler code generation.
But you'll inevitably arrive at that point and then you won't be able to
use the old libraries. For free software I would try to use the latest
everything. But there is a small problem.
The docs say that you have to link the executable with the highest
compiler version (among the versions which were used to produce object
files). That may sound reasonable, but if you give me a library compiled
with version 7 and I only have 6.2, I won't be able to use it.
Although the docs don't say explicitely, I suppose the difference is only
in startup .o files which happen to be redistributable, so in theory I
would be able to get them and then I only need to tell my 6.2 compiler to
use some other .o files. I don't know if there's a nice way to do that.
(Nice way means that I don't have to overwrite the compiler's own startup
.o files with the other ones.)
Casper H.S. Dik
>How about hardware? Some sparc builds are dependent on the
>architecture (sun4m, sun4u) even if they are for the same Solaris version.
>Perhaps there should be support for "one back" from current hardware
>platform when possible, and/or the package should not install on the
>wrong hardware. That should also prevent new users from installing
>sparc packages on x86 or viceversa.
Which builds are that?
There are no such builds by my knowledge.
(No, top, lsof, pidentd, are not such builds and never have been such
karch dependent in Solaris; you may be forgiven for thinking that
top was at one time, but that was really the case of it not working
properly on systems with an 8K page size as it assumed that
all the Sun has an 8K page size).
Other than with SunOS 4.x, there are *no* different include files
under /usr/include so whatever ARCH you build on, it all will result in
the same executable.
There's one caveat, though: some misguided versions of gcc will generate
UltraSPARC binaries by default when build on an UltraSPARC system.
So perhaps the additional architecture rules should be phrased as:
- the submitter must verify that has 32 bit binaries are pure V8
- when a package with 64 bit binaries is submitted, it should come in
to parts:
XXXfoopkg 32 bit files/isaexec copy/link; config files
XXXfoopkgx 64 bit executables/drivers.
Casper
Oscar del Rio
> >How about hardware? Some sparc builds are dependent on the
> >architecture (sun4m, sun4u) even if they are for the same Solaris version.
>
>
> There are no such builds by my knowledge.
> UltraSPARC binaries by default when build on an UltraSPARC system.
That's what I meant (perhaps with the wrong words).
I recall building some libraries (OpenSSL?) not too long ago on
an Ultra, installed it on the NFS file server, just to realize it did not
work on non-ultra machines. I had to rebuild it on a Sparc10/20
(did not have time to look for 'configure' switches to force V8 code).
Philip Brown
>...
>-L/usr/local/lib -R/usr/local/lib -Wl,-zignore -lgtk -lgdk -lXext -lX11
>-lgmodule -lglib -ldl -Wl,-zrecord
>
>I've added -zignore and -zrecord to avoid having binaries record
>dependencies on a bunch of libraries which aren't really needed. That will
>not work with Sun's CC because it doesn't understand -Wl flag.
man ld, to discover the very useful LD_OPTIONS, which fixes that problem.
assuming you dont mind using sun ld.
--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]
S.1618 http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:@@@D
http://www.spamlaws.com/state/ca1.html
Philip Brown
>...
>Or, as I suggested in another message in this thread: Why is there a
>need to transition from SFWpkg and /opt/sfw to CSWpkg and /opt/csw in
>the first place? Even if Sun doesn't want the community to help them
>keep the SFW stuff up to date, we can still do it.
>I just can't see *any* good reasons for creating yet another location
>and package name. SFW was a great idea, it was sanctioned and supported
>by Sun, and I don't see why people want to add yet another layer of
>confusion -- SFW won't go away until Sun decides to drop it.
>
>Sun doesn't hold a copyright on the "SFW" abbreviation or the /opt/sfw
>directory name. Anyone can build a package that installs to /opt/sfw,
>and name it SFWfoo. What's stopping us from doing it that way?
I personally agree with that sentiment. (although I wouldnt create the
package with the name SFWxxx)
However, Eric Boutilier of Sun specifically told us that the consensus
with the SFW team, was that they want to keep /opt/sfw for sun-created
packages.
Philip Brown
>..
>What's to be published on the community site : just the package, or option
>to download the source + pkg build scripts too? The latter sounds better to
>me : too much trust gets placed in the package builder otherwise - we've all
>seen the recent troubles with trojans sneaking into the sendmail build.
Apparently , you werent paying attention to the news, then:
the problem was with the SOURCE CODE, not the binary.
>
>> 4. Packages will be made for both Solaris 8 sparc, and Solaris 8 x86.
>> (the concept being to alwys support "one back" from "current"
>> Solaris release)
>
>So packages will be for Solaris 8 sparc+x86 and 9 sparc+x86 in the first
>instance?
yes.
in the sense that sol8 binaries work on sol9.
>> Initially, we want to make sure all packages currently covered by
>> SFW, will be covered by volunteers. Once the "existing" software is
>> covered, we will then allow signups for additional software packages.
>
>Perhaps useful if Sun showed some more community spirit and handed over the
>package sources + build scripts for all the SFW stuff, so the CSW project
>would at least get off to a quick start and none of the transition phase
>when some stuff's available on SFW and not yet on CSW ?
That would be nice. However, they have hereto been unwilling to do so.
Shao Wu
>
>
> The docs say that you have to link the executable with the highest
> compiler version (among the versions which were used to produce object
> files). That may sound reasonable, but if you give me a library compiled
> with version 7 and I only have 6.2, I won't be able to use it.
Have you tried this and failed? Or speculating there might be a
problem? So far, Workshop5 to Forte 6.2 are compatible.
I suspect not that many people are using Forte 7 compilers,
so it might not be an issue for some time to come.
Shao
Philip Brown
>> 1. A person signs up to create and maintain packages of specific free
>> software. That person is then responsible for making new releases of
>> their packages, as new versions of the software become available
>
>How "responsible" would the volunteer be for critical security updates?
>Say on a long weekend or while on vacation, a security vulnerability
>is discovered in openssl (for example) that you volunteered to maintain.
Debian has good guidelines for this sort of thing. And given that the whole
effort is modeled after debian, it makes sense to follow their guidelines.
The polite thing to do for maintainers is announce to a mailing list that
they are going on vacation.
While they are gone, in a situation like this, anyone would be authorized
to package up a security fix package.
Joe Bloggs
> On Sat, 12 Oct 2002 08:04:09 +0000 (UTC), joebl...@hotmail.com wrote:
> >..
> >What's to be published on the community site : just the package, or
option
> >to download the source + pkg build scripts too? The latter sounds better
to
> >me : too much trust gets placed in the package builder otherwise - we've
all
> >seen the recent troubles with trojans sneaking into the sendmail build.
>
> Apparently , you werent paying attention to the news, then:
> the problem was with the SOURCE CODE, not the binary.
OK. So we agree that publishing the SOURCE CODE from which the code was
built is a good idea then.
Drazen Kacar
> On 12 Oct 2002 15:30:37 GMT, da...@willfork.com wrote:
> >...
> >-L/usr/local/lib -R/usr/local/lib -Wl,-zignore -lgtk -lgdk -lXext -lX11
> >-lgmodule -lglib -ldl -Wl,-zrecord
> >
> >I've added -zignore and -zrecord to avoid having binaries record
> >dependencies on a bunch of libraries which aren't really needed. That will
> >not work with Sun's CC because it doesn't understand -Wl flag.
>
> man ld, to discover the very useful LD_OPTIONS, which fixes that problem.
> assuming you dont mind using sun ld.
Sigh.
But I don't want scripts to mess with LD_OPTIONS, even my own.
Drazen Kacar
> Drazen Kacar wrote:
> > The docs say that you have to link the executable with the highest
> > compiler version (among the versions which were used to produce object
> > files). That may sound reasonable, but if you give me a library compiled
> > with version 7 and I only have 6.2, I won't be able to use it.
>
> Have you tried this and failed?
I haven't, I rarely use C++. But that's what the documentation says.
> I suspect not that many people are using Forte 7 compilers,
> so it might not be an issue for some time to come.
Depends. I suppose edu discount is still around 100%, which would give you
many users in no time.
Drazen Kacar
> Philip Brown wrote:
> > On 12 Oct 2002 15:30:37 GMT, da...@willfork.com wrote:
> > >...
> > >-L/usr/local/lib -R/usr/local/lib -Wl,-zignore -lgtk -lgdk -lXext -lX11
> > >-lgmodule -lglib -ldl -Wl,-zrecord
> > >
> > >I've added -zignore and -zrecord to avoid having binaries record
> > >dependencies on a bunch of libraries which aren't really needed. That will
> > >not work with Sun's CC because it doesn't understand -Wl flag.
> >
> > man ld, to discover the very useful LD_OPTIONS, which fixes that problem.
> > assuming you dont mind using sun ld.
>
> Sigh.
>
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=slrn9gqkou.t5f.phil%2Bs3%40shell3.ba.best.com
>
> But I don't want scripts to mess with LD_OPTIONS, even my own.
Ah, haste...
LD_OPTIONS cannot help with this particular problem (even if I wanted to
use it from a script, which I don't) because the library order matters and
-z(ignore|record) are position dependent options. It cannot insert them
around those libraries on the command line and putting the whole
incantation in front of everything else might produce problems.
Granted, you could add -zrescan, but that looks like creating even bigger
mess instead of reducing it. Just like trying to solve runpath problems
with LD_LIBRARY_PATH.
Casper H.S. Dik
>That's what I meant (perhaps with the wrong words).
>I recall building some libraries (OpenSSL?) not too long ago on
>an Ultra, installed it on the NFS file server, just to realize it did not
>work on non-ultra machines. I had to rebuild it on a Sparc10/20
>(did not have time to look for 'configure' switches to force V8 code).
Ah, right; while I can understand fastest defaults many people still prefer
"lowest common denominator" builds.
The way we handled this for our "platform dependend" library was using
an axuilary file with '$PLATFORM' in the link path. (as libc uses;
it basically sets up a preload library which is platform specific and
does not need to exist.
If we could find some stan