Re: ProcessHandle.Info startInstant() drifts with system time on Linux

ProcessHandle; since the cached boot time does not change the value is stable for that check. A workaround for your application might be to save the relative start time by reading the boot time directly from /proc or the relative start time from /proc. Roger On 8/7/19 7:34 AM, Duft Markus wrote:

Re: [incubation] TEA Icon/Logo

esday, August 8, 2017 11:38 AM To: Duft Markus Subject: Re: [incubation] TEA Icon/Logo Hey Markus, nice logo you built there. Since you asked for feedback: the only thing that irritates me a little is the colour gradient on the "T". I guess what is strange to me is that the T is

Re: [incubation] TEA Icon/Logo

, August 7, 2017 10:49 PM To: incubation@eclipse.org Subject: Re: [incubation] TEA Icon/Logo On 2017-08-06 10:58 AM, Duft Markus wrote: Quick question regarging Logo(s). I have designed a Logo for Eclipse TEA, based on the current official Eclipse Logo. Can I use that, do I need approval from someone

Re: [incubation] TEA Icon/Logo

Subject: Re: [incubation] TEA Icon/Logo Maybe put the Eclipse logo inside the tea bag?? Or make the tea bag look like the Eclipse logo, i.e. solid dark blue with the orange peeking from behind. Neil On 7 Aug 2017, at 09:03, Duft Markus mailto:markus.d...@ssi-schaefer.com>> wrote: Hey, :D

Re: [incubation] TEA Icon/Logo

AM To: Discussions for new Eclipse projects Subject: Re: [incubation] TEA Icon/Logo Hi Markus I think some people might interpret/read the tea-full logo as OTEA not TEA. Dani From:Duft Markus mailto:markus.d...@ssi-schaefer.com>> To:"incubation@eclipse.org<mai

[incubation] TEA Icon/Logo

Hey All, Quick question regarging Logo(s). I have designed a Logo for Eclipse TEA, based on the current official Eclipse Logo. Can I use that, do I need approval from someone (who?)? Attached is the logo in two versions. Please let me know what you think :) Cheers, Markus SSI Schäfer IT Solut

[p2-dev] WG: [eclipse-dev] Installing new software with p2 is taking a long time.

Was not subscribed, so once more :) Von: Duft Markus Gesendet: Donnerstag, 18. Mai 2017 07:39 An: eclipse-...@eclipse.org; p2-dev@eclipse.org Betreff: AW: [eclipse-dev] Installing new software with p2 is taking a long time. Hey, Yes, I also observed this. It seems that any provisioning

Re: [java code coverage] Re: Problem using eclemma with Eclipse 4.4.2 (uses conflict on ASM)

Hey. We're using Secure Delivery Center to pack together a custom Eclipse package. It's based on the "standard" package however, adding quite a lot of stuff (xtext, PDE, emf, ...). Wrong version boundaries might be. What's worrying me a little is that it did not work when I tried it first, but

[java code coverage] Re: Problem using eclemma with Eclipse 4.4.2 (uses conflict on ASM)

Interestingly this only seems to happen if i try to start a debugable Eclipse in that platform. As soon as everything is rolled out to a "real" standalone Eclipse, things seem to work -- You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" gr

[java code coverage] Re: Problem using eclemma with Eclipse 4.4.2 (uses conflict on ASM)

Sorry, forgot to mention: old eclipse version was 4.4.1, so not a really major upgrade :) -- You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jacoco+uns

[java code coverage] Problem using eclemma with Eclipse 4.4.2 (uses conflict on ASM)

Hey, I tried upgrading our Eclipse to 4.4.2 release, which gives me this error: !ENTRY org.eclipse.pde.api.tools 4 0 2015-03-05 07:53:38.385 !MESSAGE FrameworkEvent ERROR !STACK 0 org.osgi.framework.BundleException: Could not resolve module: org.eclipse.pde.api.tools [1543] Bundle was not reso

RE: global_symbol_pipe not picking up an initialized globalvariable with msvc

> > > > UTL_EXPORT becomes __declspec(dllexport) when compiling > > > the shared lib, __declspec(dllimport) when compiling the > > > executable that uses it. > > > > did you double check if that really works on both sides? > > your problem sound to me as if dllimport is missing > > somewhere. > >

Re: global_symbol_pipe not picking up an initialized global variable with msvc

> Message: 1 > Date: Sat, 15 Aug 2009 21:41:26 +0200 > Subject: Re: global_symbol_pipe not picking up an initialized global > variable with msvc > Message-ID: <4a870f66.1080...@lysator.liu.se> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Den 2009-08-14 23:41 skrev David

RE: Rebase of the pr-msvc-support branch?

> > * Bob Friesenhahn wrote on Fri, Jan 09, 2009 at 06:37:18PM CET: > > It will solve a lot of problems if autotools can be used to > > build real Windows programs. > > Yes, but we need to address the efficiency issue. For example, >

RE: cccl usage

> > Den 2009-01-07 20:24, skrev Peter Rosin: > > Den 2009-01-07 20:07 skrev Ralf Wildenhues: > >> Hi Peter, > >> > >> * Peter Rosin wrote on Wed, Jan 07, 2009 at 02:09:38PM CET: > >>> Ralf, I have a vague memory of you mentioning that you knew of a > >>> project that was using cccl to provide its

RE: AM_OUTPUT_DEPENDENCY_COMMANDS problem

> > Hi! > [snip] > > Which is obviously wrong, since the '||' only makes the 'case' > conditional. This results in no 'set' being called (this $@ $* $# are > empty/0). This in turn results in the shift failing, making the while > config.status fail. Oh man, I guess writing was never my strength

AM_OUTPUT_DEPENDENCY_COMMANDS problem

Hi! I found a problem with AM_OUTPUT_DEPENDENCY_COMMANDS. I disabled dependency tracking through the configure command line option, and with recent automake (1.10.2) I kept getting errors like this: config.status: creating base/Makefile config.status: creating tools/Makefile config.status: creati

RE: GNU Make Extensions

> > On Tue, Dec 16, 2008 at 2:48 AM, NightStrike > wrote: > > On Fri, Dec 12, 2008 at 10:34 AM, Bob Friesenhahn > > wrote: > >> On Fri, 12 Dec 2008, NightStrike wrote: > >>> > >>> I thought this only occurred when "maintainer mode" was turned on, > and > >>> that releases should be made with tha

RE: GNU Make Extensions

> > > [snip] > > Also thinking this a little further: especially when I'm working at > home > on some free software, I have sometimes only half an hour or something > like that to spend on developing; I *don't* want to spend this time > maintaining the build mechanism!! Really: I don't want to do

RE: GNU Make Extensions

> > On Wed, 10 Dec 2008, NightStrike wrote: > > > > Ok, so again, I should be allowed to accept that *potential* risk as > > being far less than the current situation of *actual* risk which is > > causing problems. If I knew anything about Perl, I'd just do it > > myself, but alas, the automake s

RE: Handling of Makefile variables

> > Ralf Wildenhues wrote: > > * LCID Fire wrote on Tue, Nov 04, 2008 at 08:41:01PM CET: > >> On my app I'm currently trying to switch from one big Makefile to > >> multiple ones. > > > > Why? > > > > Besides having multiple Makefile.am files that each turn to fully > > fledged Makefile files, you

RE: fast install released already?

> > Hello Markus, > > * Duft Markus wrote on Tue, Oct 21, 2008 at 11:51:26AM CEST: > > > > I just wanted to ask wether the fast install bits are available > already > > in a released automake version? > > No, not yet. A few questions (unrelated to fas

fast install released already?

Hi there! I just wanted to ask wether the fast install bits are available already in a released automake version? Is there a single big patch for a current version? I'd really like to start using this feature, since installing out software takes hours :) we have approximately 10.000 files to insta

RE: cache problem

> > * Duft Markus wrote on Fri, Oct 17, 2008 at 09:26:44AM CEST: > > It happens when: > > > > *) configuring automake 1.9.6 with ./configure --cache-file=../cache > > *) bootstrapping libtool 1.5.24 or 26 with autoconf 2.59 > > *) configuring libt

RE: cache problem

> > * Duft Markus wrote on Fri, Oct 17, 2008 at 09:00:16AM CEST: > > > I haven't been able to do so yet. Here's what I tried. Please > modify > > > the example so that it shows the failure (maybe it only needs > different > > > flags passed to c

RE: cache problem

> > Hello Markus, > > thanks for the reports. > [snip] > > FWIW, I'm not yet sure whether this is a valid problem. Even if it is, > you should be able to work around it by adding AC_CANONICAL_HOST to the > toplevel configure.ac. But anyway, before discussing validity let's > try > to reproduc

RE: cache problem

> > Hi! > > I just noticed, that when i enable a config.cache that is used by more > than one package is problematic, when the first on checks for the build > system type only, and the second for both build and host system type. > This is, because the host system type check uses ac_cv_build_alias

cache problem

Hi! I just noticed, that when i enable a config.cache that is used by more than one package is problematic, when the first on checks for the build system type only, and the second for both build and host system type. This is, because the host system type check uses ac_cv_build_alias, which is set

RE: [gentoo-dev] bison/flex extra runtime packages

> > On Thu, Oct 16, 2008 at 09:27:29AM +0200, Duft Markus wrote: > > Now some package of mine in a local overlay requires bison and flex. > > It's quite hard to get those to build _and_ work on winnt, so I > though > > about splitting the bison ebuilds in dev-u

[gentoo-dev] bison/flex extra runtime packages

Hi there! I'm working on a "cross" compilation to native windows from an Interix Gentoo Prefix, using the normal Prefix portage tree. My setup is nearly the same as when really cross compiling, except that I can execute what I compile. I use command line utilities (DEPEND atoms) from Interix, and

RE: Noooooooooo!

> > God-damnit! please don't change autoconf to not support old style > names. Why can't you guys just make new things but still support for > older style or at least make a switch or option where if users need to > they can revert back to the old style. Progress here is like going > back 2000

RE: [patch #6448] [MSVC 7/7] Add MSVC Support

> > Not sure if I should drag this further along... So this is the last one ... :) > [snip] > > __FUNCTION__ > > Valid only within a function and returns the undecorated name of the > > enclosing function (as a string). __FUNCTION__ is not expanded if you > > use the /EP or /P compiler option.

RE: [patch #6448] [MSVC 7/7] Add MSVC Support

> > Den 2008-08-26 13:53, skrev Peter Rosin: > > Charles Wilson skrev: > >> I also think that -winnt is too broad; and I'd really hate to see > the > >> massive uglification of the libtool code -- and thousands of > >> configure.ac's out there -- that would ensue if -mingw* were > >> /officially/

RE: hppa-hpux DESTDIR support.

> > Duft Markus wrote: > > >>> Patches that do more good than harm are likely to be accepted. > >> That's exactly the point i'm unsure about, if I do more harm than > good > >> or the other way round :) of course, for _me_ I do more good, b

RE: hppa-hpux DESTDIR support.

> > > > > Duft Markus wrote: > > > > > But anyway, for me right now small side effects or very special > > > special-cases would not matter that much. It would be much more > > > important to get DESTDIR to work. However it would still be more >

RE: [patch #6448] [MSVC 7/7] Add MSVC Support

> > Peter Rosin wrote: > [snip] > > Again, I just /mentioned/ the patchlevel issue. I'm only advocating that > the API level of the ms runtime be encoded in $host. (Anything finer > grained is just as completely FUBARed^W difficult to manage as MS's > side-by-side "solution"). So then id' sugg

RE: hppa-hpux DESTDIR support.

> > Markus Duft wrote: > > Hi > > > > I'm working (together with haubi) on getting DESTDIR support for our > > hppa-hpux boxes into libtool. I now have it working, and a first > patch > > (which of course breaks some other things - I know that :( ), and > wanted to > > ask what you think about thi

RE: [patch #6448] [MSVC 7/7] Add MSVC Support

> > Markus Duft wrote: > > IMHO mingw produces code that is very different from what MSVC > produces - > > not only performance wise (in some cases). > > And remember, you can only link code generated by mingw and by msvc > together if you're using C. Not C++ or any other symbol-mangled ABI. > PL

RE: Using libltdl with the Microsoft compiler

> > * Braden McDaniel wrote on Fri, Jun 20, 2008 at 10:20:13PM CEST: > > Ralf Wildenhues wrote: > >> * Braden McDaniel wrote on Fri, Jun 20, 2008 at 11:03:04AM CEST: [snip] > > Yes, unfortunately there is still a ways to go. Btw. @Ralf: how is integration of the windows patchery going? :) has th

RE: Using libltdl with the Microsoft compiler

> [snip] > > Historically (i.e. prior to libtool 2.x), I've found that those shell > environments have not been up to the task of building my project with > the Microsoft compiler. So I've maintained a Visual C++ project file > build for that compiler. I've just recently started using libltdl in

RE: Making ORBit work with MS VS compilers

> > > Attached is our patch for ORBit2-2.14.2, which also fixes the idl > > compiler to create code that can be built into a Windows dll. > > Sorry for taking so long to get back to this issue... I haven't really > done anything about this in the meantime. I had a look at this patch > now. > > T

[gentoo-dev] RE: [gentoo-dev-announce] New developer: Michael Hammer (mueli)

> Joinin us from Graz, Austria is Michael "mueli" Hammer. He will be > joining us to maintain kerberos related packages. Michael is > responsible > for the infrastructure at the Graz University of Technology and they > run > Gentoo of course. So no longer do you have to think about moving to > othe

RE: [gentoo-alt] bootstrap with older python

> > On 05-05-2008 14:16:32 +0200, Markus Duft wrote: > > hmmm... trying to use the python built from that sources to bootstrap > i get > > this exception: > > > > Traceback (most recent call last): > > File > > "/tools/mduft/prefix-launcher-1pre.20080505/i586-pc- > interix6.0/bin/emerge", > > i

RE: [gentoo-dev] New developer : Markus Duft (mduft)

> > On 2008-05-01 03:20, Duft Markus wrote: > > Hi! > > > > Just read the mail-archive and (i'm not at work), and felt that I > have > > to say something about the binary packages on windows ;) (so sorry > for > > what the outlook web-access thin

RE: [gentoo-alt] [PREFIX] bootstrapping on Interix

> > So, I spend some time with Interix again. (I fear I'll have to use > Windows not so long from now, so who knows it can save me...) Hehehe *evil smile* :) > > > bash-3.2$ objdump > objdump: error in loading shared libraries > libopcodes-2.18.so: cannot open shared object file: No such fil

RE: [gentoo-alt] bootstrap with older python

> > On 22-04-2008 08:31:51 +0200, Duft Markus wrote: > > Hi > > > > I now have a patch ready for portage, which allows bootstrapping with > > older python versions (which i really need...). It simply disables > > manifest verification for downloaded files when

AW: [gentoo-dev] New developer : Markus Duft (mduft)

Hi! Just read the mail-archive and (i’m not at work), and felt that I have to say something about the binary packages on windows ;) (so sorry for what the outlook web-access thingy does to emails and threads :)) Right now we start using Gentoo Prefix as the primary development environment at o

RE: [gentoo-dev] New developer : Markus Duft (mduft)

> It's my pleasure to introduce Markus Duft (mduft) as a new developer. > He will go among us under the name of mduft, and will work in the > Gentoo/Alt project porting Gentoo Prefix to Interix. Yes, people, that > means Gentoo on Win32. Hope this doesn't scare away people ;o) Did you have to blaz

RE: [gentoo-alt] bootstrap with older python

Duft Markus <mailto:[EMAIL PROTECTED]> wrote: > Hi > > I now have a patch ready for portage, which allows bootstrapping with > older python versions (which i really need...). It simply disables > manifest verification for downloaded files when FEATURES=-strict hmm. thinkin

RE: [gentoo-alt] [PREFIX] stable keywords for bootstrapping

Michael Haubenwallner wrote: > On Sat, 2008-04-19 at 23:11 +0200, Fabian Groffen wrote: >> On 19-04-2008 16:07:19 -0500, matt hull wrote: Due to numerous occasions of b0rkerage in the bootstrap snapshots, bootstrapping has failed. A selection of issues that com

[gentoo-alt] bootstrap with older python

Hi I now have a patch ready for portage, which allows bootstrapping with older python versions (which i really need...). It simply disables manifest verification for downloaded files when FEATURES=-strict Is this ok to apply? Cheers, Markus portage-manifests.patch Description: portage-manifest

[gentoo-alt] portage strict feature

Hi! i have some problems with manifest verification while bootstrapping with python 2.4 (have not managed to upgrade that one). it seems that the strict feature no longer disables that verifications as - i believe - it was before. i changed this: 3606 verified_ok,r

RE: [gentoo-alt] RE: force certain USE flags per package.

Fabian Groffen <mailto:[EMAIL PROTECTED]> wrote: > On 17-04-2008 09:47:35 +0200, Duft Markus wrote: >> Duft Markus <> wrote: >>> Hi! >>> >>> How can i mask (or force) a certain USE flag on a per package basis? >>> i tried package.use,

[gentoo-alt] RE: force certain USE flags per package.

Duft Markus <> wrote: > Hi! > > How can i mask (or force) a certain USE flag on a per package basis? > i tried package.use, but that seems to just change the default (?). > while searching i also saw package.use.force somewhere on the net, > but that isn't used i

[gentoo-alt] force certain USE flags per package.

Hi! How can i mask (or force) a certain USE flag on a per package basis? i tried package.use, but that seems to just change the default (?). while searching i also saw package.use.force somewhere on the net, but that isn't used i think. Cheers, Markus -- gentoo-alt@lists.gentoo.org mailing list

[gentoo-alt] maybe helpfull scripts...

Hi just wanted to shared some scripts i use to work on my interix port... they're for sure not clean code yet, but still :) maybe somebody finds them usefull. efindkwonly: find all ebuilds where only keywords changed. einstallkw: install all packages that have a certain keyword (i use this to ver

RE: [gentoo-alt] svn not working again?

Duft Markus <mailto:[EMAIL PROTECTED]> wrote: > Hi > > Is anybody else experiencing problems svn up'ing? i get "svn: > Connection closed unexpectedly" all the time. hah, seems that switching the svn checkout to https workes around this for now: "svn switc

[gentoo-alt] svn not working again?

Hi Is anybody else experiencing problems svn up'ing? i get "svn: Connection closed unexpectedly" all the time. Also something i have noticed before: we're behind a proxy, and it seems that only one at a time can update (if it works...), all others get that "svn: Connection closed unexpectedly" me

RE: [gentoo-alt] eselect + bashcomp -- does it work in prefix?

Fabian Groffen <mailto:[EMAIL PROTECTED]> wrote: > On 03-04-2008 08:05:32 +0200, Duft Markus wrote: >> Jeremy <mailto:[EMAIL PROTECTED]> wrote: >>> So, I have eselect bashcomp enabled but when I try to tab complete >>> some eselect command either nothing hap

RE: [gentoo-alt] eselect + bashcomp -- does it work in prefix?

Jeremy wrote: > Hey all, > bug 214459 inspired me to look into eselect and bash completion. I > question its reliability. > > % eselect bashcomp list > Available completions: > [1] cowsay * > [2] eselect * > [3] genlop * > [4] subversion * > [5] vim *

RE: [gentoo-alt] --with-root-user

Fabian Groffen <mailto:[EMAIL PROTECTED]> wrote: > On 02-04-2008 15:22:27 +0200, Duft Markus wrote: >>> Feels like quite ancient to me, yes, but IIRC, portage.const should >>> exist there too. Does 'import portage' work with your >>> (bootstrapp

RE: [gentoo-alt] --with-root-user

Fabian Groffen <mailto:[EMAIL PROTECTED]> wrote: > On 02-04-2008 10:56:28 +0200, Duft Markus wrote: >> Hi! >> >> ImportError: No module named portage.const > > > >> configure: error: bad value for --with-root-user >> >> !!!

[gentoo-alt] --with-root-user

Hi! Since a few days i keep getting this when trying to bootstrap on interix (and here it's not the lib dirs): >>> Compiling source in >>> /opt/gentoo/var/tmp/portage/sys-apps/portage-2.2.00.9583/work/prefix-portage-2.2.00.9583 >>> ... Traceback (most recent call last): File "", line 1,

RE: [gentoo-alt] [PREFIX] The lost case of OpenBSD

Fabian Groffen wrote: > On 28-03-2008 23:30:22 -0700, alessandro salvatori wrote: >> has somebody setup some page with the current progress on Interix? > > Good question, I failed after patch, as all other necessary packages > don't compile out of the box. The steps i u

RE: [gentoo-alt] [PREFIX] Interix coreutils -> df?

Fabian Groffen wrote: > I got problems compiling coreutils, it keeps complaining that it can't > determine how to read list of mounted file systems. There is a patch fixing this in the tree. > > Now the ebuild seems to do some "working around broken headers", which > I

RE: Making ORBit work with MS VS compilers

Tor Lillqvist <> wrote: >> it was built with cl.exe as native win32 executable, and not with >> mingw gcc (which i think would result in a mess, since the compiler >> couldn't convert the mingw unix style paths to something that cl.exe >> understands))? > > You misunderstand. MinGW produce

RE: Making ORBit work with MS VS compilers

Tor Lillqvist <> wrote: >> Then you really should consider trying parity. Although we're on >> Interix, there should be no reason to not operate on Cygwin as build >> environment. > > Maybe with parity it's different but at least when building stuff on > Windows using the "normal" autofoo and li

RE: Making ORBit work with MS VS compilers

Michael Haubenwallner wrote: > On Mon, 2008-03-17 at 21:08 -0700, Marcelo Vanzin wrote: > >> Since you've been using ORBit on Windows, did you have to make any >> modifications to libIDL? I moved into playing with the IDL compiler >> and ran into issues because of libIDL

RE: [gentoo-alt] [PREFIX] Interix bootstrapping

Fabian Groffen <mailto:[EMAIL PROTECTED]> wrote: > On 20-03-2008 08:26:15 +0100, Duft Markus wrote: >> Fabian Groffen <mailto:[EMAIL PROTECTED]> wrote: >>> On 19-03-2008 23:05:43 +0100, Fabian Groffen wrote: >>>> Currently I am with stunning amazement l

RE: [gentoo-alt] [PREFIX] Interix bootstrapping

Fabian Groffen wrote: > On 19-03-2008 23:05:43 +0100, Fabian Groffen wrote: >> Currently I am with stunning amazement looking at how bash-3.2 is >> configuring without problems on Interix using a slightly hacked up >> bootstrap-bash.sh script. If that finishes, I'm reall

RE: [gentoo-alt] [PREFIX] The lost case of OpenBSD

Fabian Groffen <mailto:[EMAIL PROTECTED]> wrote: > On 19-03-2008 13:01:39 +0100, Duft Markus wrote: > > Why don't we upgrade to python 2.5 in the prefix-launcher? I did the > same in bootstrap-prefix recently, as the prefix tree only contains > python 2.5 as well. Y

RE: [gentoo-alt] [PREFIX] The lost case of OpenBSD

Fabian Groffen <mailto:[EMAIL PROTECTED]> wrote: > On 19-03-2008 11:42:21 +0100, Duft Markus wrote: >> Duft Markus <mailto:[EMAIL PROTECTED]> wrote: >>> Fabian Groffen <mailto:[EMAIL PROTECTED]> wrote: >>> >>> The rest can be done as describ

RE: [gentoo-alt] [PREFIX] The lost case of OpenBSD

Duft Markus <mailto:[EMAIL PROTECTED]> wrote: > Fabian Groffen <mailto:[EMAIL PROTECTED]> wrote: > > The rest can be done as described in the prefix-launcher bootstrap > WIKI [2]. Hope this works, i'm just about to bootstrap a new prefix > again too, but have

RE: [gentoo-alt] [PREFIX] The lost case of OpenBSD

alessandro salvatori wrote: > Fabien, > >one of the last times I had been to Paris I stumbled upon a group > of guys that were going to the pkgsrc conference, and joined them to > learn more... > > apparently pkgsrc "ports" are available for Interix, so perhaps some

RE: [gentoo-alt] [PREFIX] The lost case of OpenBSD

Fabian Groffen wrote: > I think I'll give up on bootstrapping on OpenBSD. Not only is the > machine (Athlon64X2 3800+) with OpenBSD slower than my Solaris/Sparc > 502MHz machine, but both binutils and GCC appear to not know anything > about the target x86_64-pc-openbsd4.

RE: Making ORBit work with MS VS compilers

Tor Lillqvist <> wrote: >> You might want to have a look at parity[1] (formerly called wgcc[2]) >> to build native Windows binaries using VisualStudio compilers. > First of all, Hi :) I'm the author of parity. > Is there any webpage give a higher-level technical description of what > parity is

RE: [gentoo-alt] [PREFIX] The libgcc linking case

Fabian Groffen <mailto:[EMAIL PROTECTED]> wrote: > On 11-03-2008 10:18:51 +0100, Duft Markus wrote: [[...]] >> >> I just tried to bootstrap on our solaris box (with gcc 4.2.3 in this >> case...). Any hints what to do here? > > What phase of the bootstrappin

RE: [gentoo-alt] [PREFIX] The libgcc linking case

Hi! Fabian Groffen wrote: > On 09-03-2008 22:31:33 +0100, Fabian Groffen wrote: >> Well, I have to test what Linux and Solaris do with this, but on >> Darwin this horribly failed. > [[...]] > > (It works on Solaris as intended) Not sure wether this is related: 10

RE: w32 ports of Libtool

Hi! Peter Rosin <mailto:[EMAIL PROTECTED]> wrote: > On Mon, Mar 10, 2008 at 08:50:16AM +0100, Duft Markus wrote: [[...]] > > (minor notes for the wgcc patch: > 1. I would drop the PARITY_CFLAGS variable and instead use > symtab_cflags="$symtab_cflags -xc++

RE: fast make install

Hi! Wow. I have a work package pending which should make our build tool on top of autotools make "bulk-install", which is exactly the thing you just committed :) will this make it into the next release for all file types? Or can i get this whole thing as a patch for the version of automake we curr

RE: w32 ports of Libtool

Hi Ralf, Peter! Peter Rosin wrote: > On Sun, Mar 09, 2008 at 02:53:20PM +0100, Ralf Wildenhues wrote: >> Hello Peter, Markus, >> >> in order to give some perspective for both of your w32 ports of >> Libtool: when we make the switch to git as primary repo, we intend >> t

RE: Libtool HEAD on Windows.

Hi! Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: > * Duft Markus wrote on Mon, Mar 03, 2008 at 09:33:44AM CET: >>>> [[...]] >> >> Still waiting for _something_... > > Sorry about being completely silent. Your patch is intrusive in that > it

RE: Libtool HEAD on Windows.

Hi! Duft Markus <> wrote: > Hi! > > Duft Markus <> wrote: >> Hi! >> [...] >> >> Attached is both a log for configure/build and the complete >> testsuite, and a patch against current HEAD. > > Has anybody looked into this yet? I'

RE: Libtool HEAD on Windows.

Hi! Duft Markus <> wrote: > Hi! > [...] > > Attached is both a log for configure/build and the complete testsuite, > and a patch against current HEAD. Has anybody looked into this yet? I'm afraid this won't apply anymore when it's finally reviewed. Cheers,

RE: [patch/rfc] setting version type based on vendor

Hi! Ralf Wildenhues <> wrote: > Hello Mike, > > Please post patches to the libtool-patches list in the future, thanks. > > * Mike Frysinger wrote on Sat, Feb 16, 2008 at 09:48:52AM CET: >> i dont know if there's a policy on this, but we've been treating the >> shared libraries in the Gentoo/Free

RE: [patch/rfc] setting version type based on vendor

Hi! Ralf Wildenhues <> wrote: > Hello Mike, > > Please post patches to the libtool-patches list in the future, thanks. > > * Mike Frysinger wrote on Sat, Feb 16, 2008 at 09:48:52AM CET: >> i dont know if there's a policy on this, but we've been treating the >> shared libraries in the Gentoo/Free

Libtool HEAD on Windows.

Hi! I now have the parity patches for HEAD ready. I ran the testsuite for interix/gcc and cygwin/gcc too, and both still behave the same as without the patch applied. I haven't had the chance to test any other platform, but I tried to take good care and not introduce any breaking changes. If there

RE: Config.guess support for i586-pc-winnt

Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: > Hello Markus, > > * Duft Markus wrote on Mon, Feb 11, 2008 at 04:06:47PM CET: >> (where does config.guess really come from? I know there is a >> gnuconfig package at gentoo). > [...] >> Sorry if this is not t

Config.guess support for i586-pc-winnt

Hi! I have ported libtool to support native windows through parity (http://www.sf.net/projects/parity). For this reason I also needed to adapt config.guess to know my compiler. I have patches ready for a few versions of automake (from 1.4 onwards, I attached only the latest two) (where does config

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Duft Markus <> wrote: > Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: >> You have several options to avoid this failure: >> >> - find out why timestamps are not in the right order after >> libtoolize --ltdl=sub/ltdl >> >> (inside s

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Ralf Wildenhues wrote: > You have several options to avoid this failure: > > - find out why timestamps are not in the right order after >libtoolize --ltdl=sub/ltdl > > (inside sub/ltdl, configure.ac should come before aclocal.m4 should > come before configure and Ma

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Duft Markus <> wrote: > Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: >> >> Thanks, I forgot about the need to 'make install' first. >> >> Does ls have an option to show full time stamp resolution? If yes, >> please repeat the a

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Ralf Wildenhues wrote: > > Thanks, I forgot about the need to 'make install' first. > > Does ls have an option to show full time stamp resolution? If yes, > please repeat the above after 'rm -rf t', using the option with both > ls invocations. Ok, i added --full-time.

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Duft Markus <> wrote: > Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: > > Hi Ralf! > > Since the commands reported errors/warnings at first, i did a gmake > install before repeating. I attached both logs. Hi! I finally found the real error :) Seems i was just

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Ralf Wildenhues wrote: > Please enter the top build directory, execute these commands, and post > log-interix1.gz: > > ( mkdir t > cd t > ../libtoolize --copy --ltdl=sub/ltdl > ls -lart sub/ltdl > rm -rf sub > ../libtoolize --ltdl=sub/ltdl > ls -lart sub/ltdl > cd ../tes

Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Hi! I have ported (again) libtool to windows using parity. No I'm stuck with the last three testsuite failures, which I just can't find causes for... Could you please have a look at this? I also attached the patch I use to get things rolling :) I plan to add some more comments, etc. So this is no

Subject: [libtool 2.1c] testsuite: 44 45 46 failed

Hi! I have ported (again) libtool to windows using parity. No I'm stuck with the last three testsuite failures, which I just can't find causes for... Could you please have a look at this? I also attached the patch I use to get things rolling :) I plan to add some more comments, etc. So this is no

RE: _AS_LN_S_PREPARE question

Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: > * Duft Markus wrote on Mon, Feb 11, 2008 at 07:59:48AM CET: >> Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: >>> >>> Is there a LD_PRELOAD-like mechanism on windows, by which you can >>>

RE: _AS_LN_S_PREPARE question

Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: > * Duft Markus wrote on Mon, Feb 11, 2008 at 07:59:48AM CET: >> Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote: >>> >>> Is there a LD_PRELOAD-like mechanism on windows, by which you can >>>

RE: _AS_LN_S_PREPARE question

Hi Ralf! Ralf Wildenhues wrote: > > Is there a LD_PRELOAD-like mechanism on windows, by which you can > intercept all open-like library calls? > suggests there isn't > one. Hm, i implemented LD_PRELOAD fully, but by conce

  1   2   3   >