[I found a typo "gcc" instead "gnu", see below the
correct word "gnu" - marked with ***, please discard
the previous mail]
Hi Milan,
thanks for having a look at this experimental version :)
I'll try to narrow down what the SFE default should be.
I came to the view that we (SFE) have one new feature
ready for use and only one important question left to
answer and a recommendation.
Feature, long term, ready for use:
these directories does SFE want as location for
libgcc_s.so.1 and libstdc++.so.6 :
/usr/gcc/<major.minor>/lib/
and if not found in the directory above, then a
potentially upgraded runtime version is in place
and available as symbolic links here:
/usr/gcc/lib/
the runtime for *our* packages compiled with this new
gcc package does not longer need to live in a public
directory. For old binaries, see symlinks right below.
Question:
for how long does SFE want to maintain "compatibility"
symbolic links for gcc runtime e.g. in
/usr/gnu/lib/libgcc_s.so
-> /usr/gcc/<major.minor>/lib/libgcc_s.so
We could tag the gcc runtime location /usr/gnu/lib as
***
deprecated but still provide the gcc-runtime-libs for
4.5.x and 4.6.x, and for e.g. gcc 4.7 stop delivering
those symlinks.
Who is using runtime libraries in old locations like
/usr/gnu/lib/ (or /usr/lib/) ? Those should be only
SFE packages compiled with old gcc without the new
configuration.
Workaround: Recompile the packages, or make symbolic
links locally in /usr/gnu/lib or run the binaries
with LD_LIBRARY_PATH pointing to e.g. the new permament
location /usr/gcc/lib. All this hits users only at the
thime when we stop providing symlinks to the runtime
in /usr/gnu/lib.
Providing good defaults.
For SFE I think we could keep the symbolic links for the
compilers in /usr/gnu/bin for a while longer. The gcc-
runtime-libs in /usr/gnu/lib sould be retired earlier, as
only not yet recompiled packages or binaries compiled on
other gcc configurations do need them.
I hope that *no* distribution gets into the idea to
provide symbolic links /usr/gnu/bin/gcc and /usr/gnu/bin/g++ !
Recommendations.
spec files could use
CC=/usr/gnu/bin/gcc
or
CC=gcc
PATH=/usr/gcc/bin:$PATH
to be sure to use a SFE provided gcc compiler binary.
Once the majority of users has the new gcc packages, then
spec files can start using CC=/usr/gnu/bin/gcc similar
to what we do with studio compilers.
BuildRequires: SFEgcc (preferred)
Requires: SFEgcc-runtime
or
BuildRequires: SFEgcc-46 (if code needs 4.6.x)
Requires: SFEgcc-runtime-46
or
BuildRequires: SFEgcc-45 (if code needs 4.5.x)
Requires: SFEgcc-runtime-45
Warning:
Using CC=gcc might lead to different results on different
distros, as you can't be sure to not stumble over e.g.
S11 provided gcc 4.5.x or gcc 3.4.3 as /usr/bin/gcc
(depending on PATH *and* distro release).
The spec file then needs logic to depend on the correct
runtime packages.
All the above is SFE centric and tries to stay safely away
from what the distros provide.
A distro may tweak the spec file and add more symbolic links
to the compiler binaries, but this should always be done in
a way that doesn't break SFE spec files. In particular the
spec files should not rely on stuff the distro has added.
This is only to please the users outside of the SFE use
and make it little bit more like a Linux (or something).
Regards,
Thomas
On Tue, Sep 27, 2011 at 09:56:15PM +0200, Milan Jurik wrote:
> Hi Thomas,
>
> introduction of /usr/gcc/lib is good solution. Thank you for making it.
> And as always, we can backout it if it will be necessary ;-)
>
> But, please, clean up SFEgcc-runpath.spec before you will promote it to
> SFEgcc because it is unmaintainable to have so many build options.
>
> Best regards,
>
> Milan
>
> Thomas Wagner pÃÅ¡e v Ãt 27. 09. 2011 v 17:33 +0200:
> > Hi all,
> >
> > if you have time for a review, I would ask you to give a
> > short or long feedback until end of the week.
> >
> > I plan to make the changes into the regular SFEgcc
> > if there are no stoppers found.
> > I'll make a copy for 4.5.3 version at the same time.
> >
> > On the other hand, the changes are compatible with what
> > we have now in SFEgcc, so only later on if we start
> > removing /usr/gnu/lib/<gcc-runtimelibs> the programs
> > compiled with older gcc might need a simple recompile/
> > packaging to use the new technique to always find the
> > runtime.
> >
> > In short, the main change is that we can get rid of
> > /usr/gnu/lib/<gcc-runtimelibs> and /usr/lib/<gcc-runtimelibs>
> > completely and stay safe with our SFE packages, regardless
> > what weird ways gcc from each distro goes.
> >
> > In parallel I'll ask Rainer Orth if he has news from the
> > gcc side for a long-term solution for finding the runtime libs.
> >
> > Thanks much
> > Thomas
> >
> > On Fri, Sep 23, 2011 at 08:13:54PM +0200, Thomas Wagner wrote:
> > > [sorry for the long text, please take a coffee and read on]
> > >
> > > Hi All,
> > >
> > > things have settled a bit now, the experimental/SFEgcc-runpath.spec
> > > does fine so far on a Solaris11 build 170. Other releases and
> > > platforms are encouraged to test *now*. Remember to remove the
> > > SFEgcc + SFEgccruntime before compiling the new version to avoid
> > > runing into problems (e.g. have old gcc 4.5.3)
> > >
> > > About experimental/SFEgcc-runpath.spec:
> > > =======================================
> > > New package names added
> > > -----------------------
> > > The latest change was reorganizing the symbolik links to be
> > > contained in the well known package names SFEgcc and SFEgccruntime.
> > > This enables all customer packages compiled with earlier SFEgcc
> > > to still find the runtime in /usr/gnu/lib/*
> > > (Some day in the future I would like to retire the symlinks
> > > in /usr/gnu/lib/* pointing to the runtime in /usr/gcc/4.6/lib.
> > > But not now.
> > > To be have permanent support for the idea of cross-version
> > > runtime libs the private directory /usr/gcc/lib is now defined.
> > > If you don't care much on the runtime version, your program
> > > just can find a recent runtime there. A default and searched
> > > first and preferred location for the runtime is /usr/gcc/4.6/lib/.
> > >
> > > New is package SFEgcc-46 and SFEgccruntime-46 which contain
> > > all the files in the somewhat private and well known directory
> > > /usr/gcc/4.6/<lib|bin> and below.
> > >
> > > You can think of future updates to SFEgcc, say version 4.7, and
> > > this can be installed as well in parallel. Only the symbolic
> > > links delivered by version 4.7 of SFEgcc and SFEgccruntime
> > > would then point to files in the new directory /usr/gcc/4.7/ .
> > > Old programs would then run the updated runtime libs 4.7.
> > > (distro builders or personal repos:
> > > A copy of future 4.7 spec file used as version 4.6 would
> > > continue to deliver SFEgcc 4.6 files and the package with
> > > the symlinks would be overwritten by subsequently published
> > > 4.7 version packages of the same name and this is installed
> > > by default then) (or a smarter solution then that)
> > >
> > > About the symlinks (locations are set at compile time)
> > > ------------------
> > >
> > > You can now predefine inside the spec file where on the disk
> > > the symlinks should go (runtime and the compiler).
> > > The current SVN version of the spec does place symlinks into
> > > /usr/gcc/<lib|bin>
> > > and as well into
> > > /usr/gnu/<lib|bin>.
> > > This list can be extended, but be aware that all those symlinks
> > > are put into one single package name SFEgcc and SFEgccruntime
> > > respectively. No separate packages for the different locations
> > > from listed above (for now).
> > >
> > > If you want to experiment with additional locations, run the
> > > whole build process once, then right after that make your
> > > new locations to the spec file and do another install/packetize
> > > cycle like described below.
> > > call pkgbuild to do another install to /var/tmp/pkgbuid*/* :
> > >
> > > pkgbuild --short-circuit -bi experimental/SFEgcc-runpath.spec
> > >
> > > check results with find /var/tmp/pkgbuild*/SFEgcc* -type l
> > >
> > >
> > > next do a fresh publishing to the repo:
> > > pkgbuild --short-circuit -bb experimental/SFEgcc-runpath.spec
> > >
> > > use the package:
> > > pfexec pkg install SFEgcc
> > > test results
> > >
> > > remove packages again, note you have 4 packages now
> > > pfexec pkg uninstall SFEgcc SFEgcc-46 SFEgccruntime SFEgccruntime-46
> > >
> > > Check contents and dependencies by reading the packages' contents
> > > entirely:
> > > pkg contents -r -m SFEgccruntime | less
> > >
> > >
> > > Linker to be used
> > > -----------------
> > >
> > > I changed ld-wrapper to /usr/bin/ld, just to be sure if a user doesn't
> > > run with CBE installed, the Solaris linker is still be found.
> > > /opt/*bld/bin/ld-wrapper inserts a few switches which might make
> > > sense on Solaris. It is possile that out include/*inc files already
> > > contain similar stuff, to we only loose switches in rare special
> > > situations. This is not yet verified. Volunteers?
> > >
> > > md_exec_prefix gcc specs
> > > ------------------------
> > >
> > > At the moment this points not longer to /usr/ccs (/bin). Instead I placed
> > > /usr/gcc there but I'm not totally sure which setting is better with
> > > the recent changes we've seen in Solaris 11 EA where /usr/ccs/bin is now
> > > a complete set of /usr/bin due to being just a symlink now. There is no
> > > longer a well selected subset (around 45) of Solaris related tools needed for
> > > compiling, instead the whole >2000 binaries known as /usr/bin/ are
> > > now reached via /usr/ccs/bin/ symlink.
> > >
> > > md_exec_prefix is a place where gcc searches refardless of $PATH
> > > for some system tools like "ld".
> > > Try this:
> > > gcc -print-prog-name=ld
> > >
> > > Maybe you can just ignore this and let others care :)
> > >
> > >
> > > note on finding runtime libs
> > > ----------------------------
> > >
> > > again, the experimental/SFEgcc-runpath.spec already contained
> > > a patch so that the gcc runtime is always found properly even
> > > if no libgcc_s.so.1 and libstdc++.so.6 is anywhere in the
> > > linker's standard search locations (/lib:/usr/lib) or optional
> > > directories (/usr/gnu/lib:/usr/sfw/lib and the like).
> > >
> > > Binaries compiled with this special gcc do find theyr runtime
> > > due to the extra code in the macro shown with
> > >
> > > /usr/gcc/4.6/bin/gcc -dumpspecs | ggrep -A2 link_libgcc
> > > *link_libgcc:
> > > %{m64:-R /usr/gcc/4.6/lib/amd64:/usr/gcc/lib/amd64 %D}%{!m64:-R /usr/gcc/4.6/lib:/usr/gcc/lib %D}
> > >
> > > I want to say thanks to the pkgsrc people or whoever found
> > > out about this setting. It just solved the problem to find
> > > the runtime always where *we* want it to be found. It works
> > > so elegantly. I just had to find the right macro syntax to
> > > switch between 32/64 bit.
> > >
> > > A binary compiled with this gcc should be robust against a
> > > distro provided runtime lib of the same name in many cases.
> > >
> > > Still to be verified is, if we need to specify an extra
> > > -R/usr/gcc/lib in out spec files in a special case. This
> > > is if there is another directory containing (accidentially)
> > > another copy of the gcc runtime libraries.
> > > In the example this is /eleswhere/lib containing as well
> > > a gcc runtime lib. The spec file contains an added
> > > -R /elsewhere/lib which *might* leads to searching for the
> > > runtime libs in this path: /elsewhere/lib:/usr/gcc/4.6/lib:/usr/gcc/lib
> > > I found no solution to really force the link_libgcc
> > > location be *ever* the very first one in search order.
> > > The Solution for this rare cases is:
> > > The *FLAGS setting would then be -R/usr/gcc/lib:/elsewhere/lib
> > > to visit the gcc runtime we want first, then the rest.
> > >
> > > If we are in luck, other distros might just adopt this setting
> > > of link_libgcc and we can live in a trouble free world with
> > > *not a single* gcc runtime in /lib:/usr/lib - and still have
> > > each binary find what it expects, its very own runtime it
> > > was compiled against, or a more recent one which is still
> > > under SFE control in e.g. /usr/gcc/lib.
> > > This should end the "mix the runtime and get in troubles"
> > > era with gcc.
> > >
> > > Well, I'll end for now with this news. In any case please
> > > ask if you have questions or want to express optinions,
> > > please do. But please, try a little serious research before
> > > expressing objections.
> > > It was a lot work for research and testing put into this
> > > new settings, and from my view this looks very well.
> > > If not, then this maybe means I should talk more about
> > > the reasons behind something looking odd to you.
> > >
> > > Regards,
> > > Thomas
> > >
> > >
> > > On Wed, Sep 14, 2011 at 12:14:57AM +0200, Thomas Wagner wrote:
> > > > Hi All,
> > > >
> > > > small update after a little vacation.
> > > >
> > > > I have now an experimental SFEgcc.spec and small patches to
> > > > get the solaris configs adjusted.
> > > >
> > > > What in the experimental spec file works now is, that a gcc or
> > > > g++ compiled binary now really finds its libgcc_s.so.1 and
> > > > libstdc++.so.6 on its own, without having to specify any
> > > > -R/path/to/lib/lib<gcc|stdc++>.
> > > > This enables a "plain" gcc or g++ run without and switches
> > > > and still find the runtime even if it is stored in a
> > > > non-default place to be out of reach of other software
> > > > which should not find is.
> > > > This spec make the gcc runtime libs be searched in
> > > > /usr/gcc/4.6/lib and /usr/gcc/lib (new, thought as a new
> > > > default place for them).
> > > >
> > > > A separate change is, that there is no hardcoded -R /usr/gnu/lib
> > > > any more, this enables us to freely specify to include this
> > > > formerly ever-hardcoded /usr/gnu/lib path for searching
> > > > all sorts of librares or leave it out completely.
> > > > Andditionally we get back more choice in specifing in which
> > > > odering the "***/lib" directores are searched.
> > > > (e.g. /usr/lib:/usr/gnu/lib to find Solaris native libs first,
> > > > or think of other combinations. *) small exception see below )
> > > >
> > > > I have one more experiment to do, this is testing if we can
> > > > re-establish a small fraction of the old gcc-03*diff patch,
> > > > but now with hardcoding /usr/gcc/4.6/lib:/usr/gcc/lib into
> > > > the binaries to search for the runtime libs. This would still
> > > > avoids having all-purpose /usr/gnu/lib even if we don't want
> > > > the other libs from there. And more imporant, we can really
> > > > make sure that other libgcc_s.so.1 and libstdc++.so.6 do
> > > > never slip in and get found before our well-known-tested-good
> > > > own SFEgccruntime libs.
> > > >
> > > >
> > > > I'll try to make the experimental SFEgcc with the new patches
> > > > available until end of this week (Friday or Saturday).
> > > > If someone is impatient, drop me a mail and I'll quickly make
> > > > a tarball of the files for you.
> > > > I want to compile a few representative SFE specs and if this
> > > > doen't present any problems, we can discuss if this is the
> > > > way for SFE to go in gcc-4.x.x settings.
> > > >
> > > > Regards,
> > > > Thomas
> > > >
> > > >
> > > > *) exception is currently, that gcc doesn't allow to place
> > > > the runtime libs directory in any case as the *first* directory
> > > > to include. I'll see if a patch like the old gcc-03-*diff
> > > > can force the gcc runtime libs directory to be search always
> > > > first, regardless what the user puts in his -R/path/to/lib.
> > > > Today the runtime libs directory might be prepended by the
> > > > path from -R, e.g. /path/to/lib:/usr/gcc/4.6/lib:/lib/usr/lib
> > > > This is as long the system is not pulluted by other libgcc_s.so.1
> > > > and libstdc++.so.6 library files
> > > >
> > > > On Fri, Sep 02, 2011 at 10:59:49PM +0200, Thomas Wagner wrote:
> > > > > Just a quick question, what is what we really want to achieve?
> > > > >
> > > > > Is this having a gcc compiled binary just find the gcc own libraries?
> > > > > Nothing else?
> > > > >
> > > > > In this case we could save all the side effects with a hard
> > > > > -R/usr/gnu/lib (and others)
> > > > > applied to all sorts of binaries/libraries who not necessarily need it.
> > > > >
> > > > > pkgsrv does solve this different then us, as it seems.
> > > > > If we follow, this would be to add -R/usr/gnu/lib
> > > > > *only* to libgcc_s.so and libstdc++.so (gcc libs)
> > > > >
> > > > > pkgsrc uses a patch which makes gcc output this:
> > > > > (pkgsrv's version of) GCC 3.4.6 reports via
> > > > >
> > > > > gcc -dumpspecs | ggrep -A2 link_libgcc
> > > > > *link_libgcc:
> > > > > %D -R /usr/pkgsrc/20101105/gcc34/lib
> > > > >
> > > > > A patch like this is used by pkgsrc:
> > > > > http://mail-index.netbsd.org/pkgsrc-bugs/2011/08/18/msg043988.html
> > > > > or
> > > > > http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/lang/gcc34/patches/patch-cc?rev=1.1;content-type=text%2Fx-cvsweb-markup
> > > > >
> > > > >
> > > > > all our gcc variants (3.x.x, all sorts 4.x.x) do print only
> > > > > *link_libgcc:
> > > > > %D
> > > > >
> > > > > We currently force not only the gcc libs to have this runpath,
> > > > > we force all binaries/libs to use this runpath, kind of using
> > > > > nuclear bomb to kill a beatle or a bug. :-) :-)
> > > > >
> > > > > If I find time, I'll replay my testbed for the topic and see
> > > > > if the svn-current gcc-03-gnulib.diff (not forcing -R/usr/gnu/lib...)
> > > > > and another patch worked after the pkgsrc example does give us
> > > > > a gcc which compiles binaries and just finds it's own libraries,
> > > > > but not forces the old long runpath into every binary/library.
> > > > >
> > > > > Regards,
> > > > > Thomas
> > > > >
> > > > >
> > > > > On Thu, Sep 01, 2011 at 04:26:18PM +0200, Thomas Wagner wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > we had a change to SFEgcc recently where patch gcc-03-gnulib.diff
> > > > > > in the old revision just replayed what the original gcc 3.x.x from
> > > > > > Sun/Oracle did, this was hardcoding the library runpath to be
> > > > > > /lib:/usr/lib:/usr/gnu/lib and so on. I think this is not ideal
> > > > > > to hardcode the runpath just for a few benefits of not having
> > > > > > to specify runpaths when compiling/linking software.
> > > > > >
> > > > > > GCC according to theyr website says it explicitly does not add
> > > > > > any runpath and more let the full choice up to the user and what
> > > > > > he thinks the runpath should be. I believe this comes from the
> > > > > > cross-compiling world gcc supports. It might help as well in
> > > > > > difficult situations where we have one library name for more
> > > > > > then one version/variant of a lib on one system.
> > > > > >
> > > > > > <history>
> > > > > > A quick look on the history: The patch gcc-03-gnulib.diff was
> > > > > > changed to not longer hardcode the runpath. Reason was that
> > > > > > we've been unable to place /usr/g++/lib at the very beginning
> > > > > > of the runpath which was needed for QT (gcc/g++) for some
> > > > > > programs.
> > > > > > So the change to the compiler was done and tested and it worked.
> > > > > > Later on it revealed that the runtime lib searchpath wasn't
> > > > > > wrong because of gcc, it was a bad default in the qmake macros
> > > > > > of QT on solaris where the switch -W,-R, was set ( I think
> > > > > > this is from GNU-LD versus Sun-LD). A change to that macro
> > > > > > changed this to just "-R" and the root cause for the wrong
> > > > > > runpath was removed.
> > > > > >
> > > > > > Now we still have the gcc being sane, clean, without the runpath
> > > > > > hardcoded. I personally would like to leave it in this state,
> > > > > > but there is a little downside with this. Now our spec files
> > > > > > need to specify -R/usr/gnu/lib themselves to find the gcc
> > > > > > compiler runtime, because gcc doesn't do it for us hardcoded
> > > > > > any more.
> > > > > > </histroy>
> > > > > >
> > > > > >
> > > > > > I had a talk with herzen on IRC and it looks like we could keep
> > > > > > the brave gcc without hardcoded runpath and change one or two
> > > > > > of our include files according to this meta code:
> > > > > >
> > > > > > maintainer sets in his spec file:
> > > > > > %include Solaris.inc
> > > > > > %define cc_is_gcc 1
> > > > > > %include base.inc
> > > > > > (optionally: %include arch64.inc)
> > > > > >
> > > > > > #we could change those of the include files responsible for setting
> > > > > > #LDFLAGS and CFLAGS
> > > > > > %if cc_is_gcc
> > > > > > set extra %{_ldflags} to insert -R/usr/gnu/lib -L/usr/gnu/lib
> > > > > > set extra %{gcc_optflags} to insert -R/usr/gnu/lib -L/usr/gnu/lib
> > > > > > %endif
> > > > > >
> > > > > > This way, through the include files, we would not have a lot changes
> > > > > > to existing spec files but still get the /usr/gnu/lib into the runpath.
> > > > > > Some spec files would need to now set %define cc_is_gcc 1 and
> > > > > > re-include the base.inc/other_inc_files.
> > > > > > (Note, gcc4 programs need some gcc runtime libs, and those live in
> > > > > > /usr/gnu/lib, e.g. libgcc*, libstc++* )
> > > > > >
> > > > > > In case we have a complicated situation with the order of the libs
> > > > > > searchpath/runpath, then a gcc free of any hardcoded runpath might
> > > > > > help to get the libs searched in the order the maintainer needs
> > > > > > them. In this case, the user can re-define the CFLAGS/LDFLAGS to
> > > > > > have all the flags locally and not using the include files presets.
> > > > > >
> > > > > >
> > > > > > The above draws the idea, comments welcome. We could make an example
> > > > > > implementation to see if it works.
> > > > > >
> > > > > > Regards,
> > > > > > Thomas
> > > > > >
> > > > > > PS: some might be in favour of replicating in SFEgcc what gcc 3.x.x
> > > > > > does (hardcode runpath), some might want SFEgcc go back to the same
> > > > > > hardcoded runpath, some don't. As well there are thoughs if Studio
> > > > > > compilers do hardcode a runpath as well, this is to be tested with
> > > > > > simple helloworld.c and see if that is really the case and which
> > > > > > paths are in runpath with Studio. dump -Lv helloworld or a call to
> > > > > > elfdump -d helloworld shows the runpath.
> > > > > >
> > > > > > PS2: those who not have recompiled SFEgcc after around SVN version
> > > > > > from revision r3713 / 2011-08-16 10:37:16 +0200 do still place
> > > > > > hardcoded runpaths into the resulting packages.
> > > > > >
> > > > > > ~/spec-files-extra svn log patches/gcc-03-gnulib.diff
> > > > > > ------------------------------------------------------------------------
> > > > > > r3713 | tom68 | 2011-08-16 10:37:16 +0200 (Tue, 16 Aug 2011) | 2 lines
> > > > > >
> > > > > > SFEgcc.spec, gcc-03-gnulib.diff: rework RUNPATH to give user all choices
> > > > > >
> > > > > > ------------------------------------------------------------------------
> > > > > > r3246 | jurikm | 2011-03-04 23:16:03 +0100 (Fri, 04 Mar 2011) | 3 lines
> > > > > >
> > > > > > SFEgcc.spec: RUNPATH enforced to contain /usr/gnu/lib, libs symlinked to /usr/gnu/lib
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Thomas Wagner
> > > > > > +49-171-6135989 http://www.wagner-net.net
> > > > > >
> > > > > > ------------------------------------------------------------------------------
> > > > > > Special Offer -- Download ArcSight Logger for FREE!
> > > > > > Finally, a world-class log management solution at an even better
> > > > > > price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> > > > > > download Logger. Secure your free ArcSight Logger TODAY!
> > > > > > http://p.sf.net/sfu/arcsisghtdev2dev
> > > > > > _________________________________________________________________
> > > > > > SFE-devel mailing list - Pkgbuild-sfe-devel@...
> > > > > > http://pkgbuild.wiki.sourceforge.net/SFE
> > > > > > https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
> > > > > >
> > > > >
> > > > > --
> > > > > --
> > > > > Thomas Wagner
> > > > >
> > > > > ------------------------------------------------------------------------
> > > > > Service rund um UNIX(TM), Wagner Network Services, Thomas Wagner
> > > > > Solaris(TM), Linux(TM) Eschenweg 21, 89174 Altheim, Germany
> > > > > Novell(TM), WindowsNT(TM) TEL: +49-731-9807799, FAX: +49-731-9807711
> > > > > Telekommunikation, LAN, MOBILE/CELL: +49-171-6135989
> > > > > Internet-Service, Elektronik EMAIL: wagner@...
> > > > >
> > > > > ------------------------------------------------------------------------------
> > > > > Special Offer -- Download ArcSight Logger for FREE!
> > > > > Finally, a world-class log management solution at an even better
> > > > > price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> > > > > download Logger. Secure your free ArcSight Logger TODAY!
> > > > > http://p.sf.net/sfu/arcsisghtdev2dev
> > > > > _________________________________________________________________
> > > > > SFE-devel mailing list - Pkgbuild-sfe-devel@...
> > > > > http://pkgbuild.wiki.sourceforge.net/SFE
> > > > > https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
> > > > >
> > > >
> > > > --
> > > > --
> > > > Thomas Wagner
> > > >
> > > > ------------------------------------------------------------------------
> > > > Service rund um UNIX(TM), Wagner Network Services, Thomas Wagner
> > > > Solaris(TM), Linux(TM) Eschenweg 21, 89174 Altheim, Germany
> > > > Novell(TM), WindowsNT(TM) TEL: +49-731-9807799, FAX: +49-731-9807711
> > > > Telekommunikation, LAN, MOBILE/CELL: +49-171-6135989
> > > > Internet-Service, Elektronik EMAIL: wagner@...
> > > >
> > > > ------------------------------------------------------------------------------
> > > > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> > > > Learn about the latest advances in developing for the
> > > > BlackBerry® mobile platform with sessions, labs & more.
> > > > See new tools and technologies. Register for BlackBerry® DevCon today!
> > > > http://p.sf.net/sfu/rim-devcon-copy1
> > > > _________________________________________________________________
> > > > SFE-devel mailing list - Pkgbuild-sfe-devel@...
> > > > http://pkgbuild.wiki.sourceforge.net/SFE
> > > > https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
> > > >
> > >
> > > --
> > > --
> > > Thomas Wagner
> > >
> > > ------------------------------------------------------------------------
> > > Service rund um UNIX(TM), Wagner Network Services, Thomas Wagner
> > > Solaris(TM), Linux(TM) Eschenweg 21, 89174 Altheim, Germany
> > > Novell(TM), WindowsNT(TM) TEL: +49-731-9807799, FAX: +49-731-9807711
> > > Telekommunikation, LAN, MOBILE/CELL: +49-171-6135989
> > > Internet-Service, Elektronik EMAIL: wagner@...
> > >
> > > ------------------------------------------------------------------------------
> > > All of the data generated in your IT infrastructure is seriously valuable.
> > > Why? It contains a definitive record of application performance, security
> > > threats, fraudulent activity, and more. Splunk takes this data and makes
> > > sense of it. IT sense. And common sense.
> > > http://p.sf.net/sfu/splunk-d2dcopy2
> > > _________________________________________________________________
> > > SFE-devel mailing list - Pkgbuild-sfe-devel@...
> > > http://pkgbuild.wiki.sourceforge.net/SFE
> > > https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
> > >
> >
> > --
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _________________________________________________________________
> SFE-devel mailing list - Pkgbuild-sfe-devel@...
> http://pkgbuild.wiki.sourceforge.net/SFE
> https://lists.sourceforge.net/lists/listinfo/pkgbuild-sfe-devel
>
--
--
Thomas Wagner
------------------------------------------------------------------------
Service rund um UNIX(TM), Wagner Network Services, Thomas Wagner
Solaris(TM), Linux(TM) Eschenweg 21, 89174 Altheim, Germany
Novell(TM), WindowsNT(TM) TEL: +49-731-9807799, FAX: +49-731-9807711
Telekommunikation, LAN, MOBILE/CELL: +49-171-6135989
Internet-Service, Elektronik EMAIL: wagner@...
|