mingw-users Mailing List for MinGW - Minimalist GNU for Windows

On Tuesday 26 February 2008 23:16, Hans Schmucker wrote:
> I have to admit that I'm a bit helpless dealing with the likes of
> you, ...

Well then, that feeling is mutual.

> ... but let's see: 
>
> 1. Rolf wants to build something (doesn't matter what) with MinGW and
> emulated symlinks don't work, because MinGW is not a cygwin
> application. 

I don't see how that is in any way relevant; AFAICT, at no time did Rolf 
enquire about MinGW's capability to work with symlinks.

> 2. Brian points out to him that he isn't dealing with a Cygwin
> application. 

On the contrary, Brian suggested a kludge to work around the problem 
Rolf was facing.  The kludge was based on the use of symlinks, which 
would require the use of Cygwin, or perhaps, as Earnie pointed out, in 
the particular circumstances of Rolf's issue, a similar kludge using 
reparse points might be effective *without* requiring Cygwin.

> 3. I point out that he could use junctions...

...which basically was just a reiteration of the option Earnie had 
already pointed out.  (That's not a criticism; maybe you hadn't seen 
Earnie's response, when you posted yours).

> (never mind how I called them, ...

You said they were *real* symlinks, which is technically inaccurate.

> I did post a link), ...

...which was useful, thanks; no one is disputing that.

> which offers a solution.

No; it offers a possible mechanism for implementing a kludge.  A kludge 
is *never* a solution, IMO.  However, it may be expedient to adopt a 
kludge, in order to work around some problem for which no immediate 
solution is apparent; the distinction may be considered pedantic, so 
let's not dwell on it.

> 4. You start your series of lectures...

My postings had nothing whatsoever to do with `lecturing'...

> ...without offering any information that would be helpful to Rolf ...

...neither was it intended to be helpful to Rolf, who had already stated 
that he was not interested in any such form of kludged work around; it 
was intended to correct the technically inaccurate statements that you 
had made.  This was in no way intended as any form of personal affront; 
it was merely correction and clarification of information for the sake 
of preserving the integrity of the list archives.  These archives are a 
valuable resource for future reference, which is why it is important 
that such corrections of misleading information are posted, (and why it 
*does* matter that the incorrect information you posted was not allowed 
to pass into the archives without such accompanying correction).

> with the apparent aim to drive me off this list

Driving you, or anyone else, off the list could never have been further 
from my mind; if I'd wanted to do that, I could simply have invoked my 
administrative privilege, and excluded all posts from your address.

I'm sorry that you are so easily offended, when someone, (Brian and I, 
on this occasion), points out and corrects technical inaccuracies in 
some information you've posted on the list.  There are many places on 
the Internet, where you can find bad advice on using MinGW; we do not 
want this list to be one of them.  Had I myself posted technically 
inaccurate information, I should have been grateful for someone to 
correct my misconceptions; (indeed this has happened before, and I have 
no doubt it may happen again, for none of us is infallible).

Regards,
Keith.

[ Please keep replies on the list, not to me. ] 

Mark'sPublicAcct wrote:

> The others who have toiled to update gcj, are they individuals, or
> public groups?  If public, can you point me in their direction?

Start with a google of "mingw gcj", and I'm sure you'll find some hits. 
That's about all I know.

Brian

Mark'sPublicAcct wrote:

> According to Sun's documentation, the java.io.FIle class has had
> the API to create a new File object taking only a URI since jdk 1.4,
> and according to a link off od GNU's site, their support for java.io
> jdk 1.4 support is 99.84% complete (I actually couldn't find what
> comprised the .06%).

That comparison is between the current state of classpath and the JDK. 
In gcj 3.4, classpath hadn't really been fully merged with libgcj yet,
only certain parts shared.  And the classpath that was current at the
time of the branch (jan 2004) was quite old, probably around version
0.07 as far as I can tell.

> Finally, my question is; what level of JDK support am I getting
> through my MinGW libgcj-3.4.5.jar - level installation, and is there
> anyway to update/modify my installation to take advantage of the
> more-recent level of jdk support available from the GNU's latest
> gcj/classpath releases?

I think you can expect JDK 1.2 level support and not much more.  3.4 is
unfortunately quite old and gcj has changed a lot recently compared to
the other languages.  The -findirect-dispath and BC ABI didn't even
exist until 4.0, and I believe that those are required to implement some
of the more advanced language features.  And as above, the full
classpath merge didn't really happen until gcj 4 either.  AFAIK gcj 4.0
offered around JDK 1.3 or 1.4 level of compatibility.  And as of gcj
4.3, the Eclipse compiler was merged which gives full JDK 1.5 language
feature compatibility, combined with current classpath which, as you
saw, is getting fairly complete in terms of runtime compatibility.

So yes, if you want something more recent you have to use a more recent
version of gcc.  The MinGW gcc 4.2 packages do not include gcj, so
you're kind of out of luck at the moment.  I know there are other
individuals who have coaxed gcj 4.x into building for MinGW, and you may
be able to use the fruits of their toil; just remember those are other
projects so you should expect to contact them for help.

Brian

My apologies in advance for any miss-speakings here as I am new to MinGW
(and gcc):

I recently installed MinGW using the MinGW-5.1.3 installer and chose the
Java (gcj) component to install.  For version reference, the installation
included the file MinGW\share\java\libgcj-3.4.5.jar.

I have since been able to create and successfully test a
HelloWorld.exegenerated from a
HelloWorld.java file.  So far so good.

I am now trying to use gcj to similarly create an executable for my "real"
java application, however, I am getting an error at compile time indicating
this line from one of the Java files:
    File xmlFile = new File(new URI(extForm));

The message is:
    com/cfg/MDLoader.java: In class `com.cfg.MDLoader':
    com/cfg/MDLoader'.java: In method `com.cfg.MDLoader'.nstdLoad(
com.core.ext.TL,java.lang.String,com.cfg.MD)':
    com/cfg/MDLoader'.java:117: error: class 'java.io.File' has no method
named '<init>' matching signature '(Ljava/net/URI;)V'
    com/cfg/MDLoader'.java:117: error: expected type 'null' but stack
contains 'void'
    com/cfg/MDLoader'.java:118: confused by earlier errors, bailing out

According to Sun's documentation, the java.io.FIle class has had the API to
create a new File object taking only a URI since jdk 1.4, and according to a
link off od GNU's site, their support for java.io jdk 1.4
support<http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html>is
99.84% complete (I actually couldn't find what comprised the .06%).

Finally, my question is; what level of JDK support am I getting through my
MinGW libgcj-3.4.5.jar - level installation, and is there anyway to
update/modify my installation to take advantage of the more-recent level of
jdk support available from the GNU's latest gcj/classpath releases?

thanks,
Mark.

Thanks

Dave Korn wrote:

> On 27 February 2008 14:35, Nathan Braswell wrote:
>
>   
>> Hello.
>> I have been researching how to make a small compiler in c++ for a new
>> language.
>> I remember seeing some where about an example of this someplace, maybe
>> in MinGW install, or instructions, or on GNU.
>> It's name had something to do with tree, I think.
>> I was wondering if any of you had heard of this.
>>     
>
>   You are thinking of "treelang", which is a "toy" language frontend
> implemented as part of GCC, it serves as an example of how to write a new
> language frontend for gcc.
>
>   It's in the gcc sources in the ..../gcc/treelang/ dir if you unpack the full
> gcc tarball.  
>
>
>
>     cheers,
>       DaveK
>   

On 27 February 2008 14:35, Nathan Braswell wrote:

> Hello.
> I have been researching how to make a small compiler in c++ for a new
> language.
> I remember seeing some where about an example of this someplace, maybe
> in MinGW install, or instructions, or on GNU.
> It's name had something to do with tree, I think.
> I was wondering if any of you had heard of this.

  You are thinking of "treelang", which is a "toy" language frontend
implemented as part of GCC, it serves as an example of how to write a new
language frontend for gcc.

  It's in the gcc sources in the ..../gcc/treelang/ dir if you unpack the full
gcc tarball.  



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Hello.
I have been researching how to make a small compiler in c++ for a new 
language.
I remember seeing some where about an example of this someplace, maybe 
in MinGW install, or instructions, or on GNU.
It's name had something to do with tree, I think.
I was wondering if any of you had heard of this.
Thank you for your time.

Hello all,
How to acquire (from WEBCAM) an image to memory from a mingw console application?
Is there a code fragment already ported from VC to mingw?

Thank you

Ruediger
____________________________________________________
atg Luther & Maelzer GmbH  
Sitz / Company Seat       : 50668 Koeln / Germany
Strasse / Street          : Thedor-Heuss-Ring-23
Amtsgericht / Local Court : Koeln HRB 58893
USt.-Id. Nr. / VAT ID No. : DE 814 906 312
St.-Nr. / TIN No.         : 80088 / 23872 
Finanzamt / Revenue Office: Tauberbischofsheim
____________________________________________________

I have to admit that I'm a bit helpless dealing with the likes of you, but
let's see:

1. Rolf wants to build something (doesn't matter what) with MinGW and
emulated symlinks don't work, because MinGW is not a cygwin application.
2. Brian points out to him that he isn't dealing with a Cygwin application.
3. I point out that he could use junctions (never mind how I called them, I
did post a link), which offers a solution.
4. You start your series of lectures without offering any information that
would be helpful to Rolf with the apparent aim to drive me off this list

Is that an accurate summary?

On Sunday 24 February 2008 20:13, Hans Schmucker wrote:
[w.r.t. equivalence of WinNT's reparse points and symbolic links]
> The words real and symlink were only thrown in there to distinguish
> them from the "emulated symlinks" provided by Cygwin, nothing
> more.... sheesh

So, why mention it at all?  AFAIK, Cygwin's "emulated symlinks" do 
actually provide a fair emulation of real symlinks, (provided that it 
is a Cygwin application which is interpreting them).  Reparse points, 
(a.k.a. "junction points") are something else entirely; their closest 
analogue in the Unix world would be loop-back mounts, which exhibit 
rather different properties from symbolic links.

Regards,
Keith.

Doug Schaefer wrote:
> Brandon Sneed wrote:
>   
>> On Feb 17, 2008, at 7:55 PM, Brian Dessent wrote:
>>   
>>     
>>> Doug Schaefer wrote:
>>>
>>>     
>>>       
>>>> If I 'dll-symbols' load the DLL, the offsets are wrong. Using  
>>>> 'file' on
>>>> reaper.exe doesn't help at all.
>>>>       
>>>>         
>>> I think this is fixed in current CVS.  Anyway, just attach to the
>>> running process instead of starting it from gdb.  That way the libray
>>> will already be loaded when gdb starts and it should be able to read  
>>> the
>>> symbols and set breakpoints.
>>>     
>>>       
>> This isn't fixed in the current CVS.  The problem is that pending  
>> breakpoints require that some symbols be loaded already.  I've made a  
>> patch and I've been testing it here the past few weeks and it seems to  
>> work ok.  I'll try to upload a new Tech Preview early this week.
>>
>>
>> Brandon Sneed
>>
>>   
>>     
>
> Very cool. Thanks Brandon. I'll give it a try as soon as you post it.
>
> Doug
>   
Hey Brandon, do you have the patch available to download from somewhere?

Thanks,
Doug

Hello Brian, Arnaud.

> (Maybe it would be useful to add it in the "Download" section of MinGW
> site...)

I have been using the patched/built version of mingwm10 for months now
in a corporate deployment without problems.  I would also give my vote
that the mingw runtime packages be updated as the reloc problem can
cause some awful headaches that are very difficult to debug.

Just my $.02
- Dave

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Brian Dessent a &eacute;crit&nbsp;:
<blockquote cite="mid:47C...@de..." type="cite">
  <pre wrap="">Arnaud Masson wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Is there an updated version of mingwm10.dll somewhere which is safely
rebasable?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Not that I know of.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Otherwise how I can build mingwm10.dll myself and apply the patch?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Get the mingw-runtime -src package from the MinGW download area.  Unpack
the source, apply the patch, and rebuild.  You will need to install MSYS
but it should be a simple "./configure &amp;&amp; make" affair.  You might need
to manually run autoconf in order to regenerate Makefile from
Makefile.in, if the configure script doesn't detect this for you (aka
maintainer-mode.)

Actually, that could be a lot to do if you're not familiar with autoconf
style packages.  Try the attached mingwm10.dll, it is the result of
doing the above.

  </pre>
</blockquote>
I have replaced the standard mingwm10.dll with the one you have
provided.<br>
It works fine, thanks a lot! <span class="moz-smiley-s1"><span> :-) </span></span><br>
<br>
(Maybe it would be useful to add it in the "Download" section of MinGW
site...)<br>
<br>
<br>
</body>
</html>

Arnaud Masson wrote:

> Is there an updated version of mingwm10.dll somewhere which is safely
> rebasable?

Not that I know of.

> Otherwise how I can build mingwm10.dll myself and apply the patch?

Get the mingw-runtime -src package from the MinGW download area.  Unpack
the source, apply the patch, and rebuild.  You will need to install MSYS
but it should be a simple "./configure && make" affair.  You might need
to manually run autoconf in order to regenerate Makefile from
Makefile.in, if the configure script doesn't detect this for you (aka
maintainer-mode.)

Actually, that could be a lot to do if you're not familiar with autoconf
style packages.  Try the attached mingwm10.dll, it is the result of
doing the above.

Brian

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello&nbsp;<br>
&nbsp;<br>
I wrote a plugin for IE with MinGW.&nbsp;<br>
In some configurations, it can't be loaded because mingwm10.dll cannot
be rebased (another third-party DLL has the same base address).&nbsp;<br>
&nbsp;<br>
I have found this entry in the Tracker:&nbsp;<br>
<a
 href="http://sourceforge.net/tracker/index.php?func=detail&amp;aid=1789093&amp;group_id=2435&amp;atid=302435"
 target="_blank">http://sourceforge.net/tracker/index.php?func=detail&amp;aid=1789093&amp;group_id=2435&amp;atid=302435</a>&nbsp;<br>
&nbsp;<br>
Is there an updated version of mingwm10.dll somewhere which is safely
rebasable?&nbsp;<br>
Otherwise how I can build mingwm10.dll myself and apply the patch?&nbsp;<br>
Should I download cygwin and start some script? (I don't know much
about linux build systems...)&nbsp;<br>
<br>
Thanks in advance!&nbsp;<br>
&nbsp;<br>
Arnaud<!-- google_ad_section_end -->
</body>
</html>

----- Original Message ----- 
From: "Brian Dessent" <br...@de...>

I meant to get back to this earlier. To recap - I'm trying to come to terms 
with the 'make check' failures thrown up when building GMP-4.2.2 as a shared 
library. (There's no problem when building GMP-4.2.2 as a static library.) 
My original post mentioned failures in both the msys shell and Cygwin's bash 
shell (cross-compiling for native Win32).

Let's just concentrate on the msys shell for the moment. On Windows XP, 
msys-1.0.10, building gmp-4.2.2 (shared lib), 'make check' terminates with:

>> creating t-sub.exe
>> make[4]: Leaving directory `/home/Rob/comp/gmp-4.2.2/tests'
>> make  check-TESTS
>> make[4]: Entering directory `/home/Rob/comp/gmp-4.2.2/tests
>> FAIL: t-bswap.exe
>> FAIL: t-constants.exe
>> FAIL: t-count_zeros.exe
>> FAIL: t-gmpmax.exe
>> FAIL: t-hightomask.exe
>> FAIL: t-modlinv.exe
>> FAIL: t-popc.exe
>> FAIL: t-parity.exe
>> FAIL: t-sub.exe
>
> I'd say you need to enable verbosity on these tests and find out exactly
> the nature of the failure.

Good point. I couldn't work out how to do that, so I've asked about it in 
the email I've just submitted to gmp...@sw... .

So ... let's change just one thing and revert to gmp-4.2.1. That now builds 
fine ... looks like it *is* a gmp bug.

But, on the same XP box, I also have msys-1.0.11.
In that shell, *both* gmp-4.2.2 *and* gmp-4.2.1 (when built as shared libs) 
fail to build correctly. For both versions of GMP, the 'make check' process 
hangs when the first test executable is run. I've since tried running some 
of the other test executables individually, and they all cause a hang.

The fact that GMP-4.2.1 builds ok dynamically in msys-1.0.10 but not 
dynamically in 1.0.11 would suggest that something changed between 1.0.10 
and 1.0.11 - and GMP does not like that change. Of course, that doesn't mean 
it's an msys bug.

Let's now throw in an additional layer of confusion ... with just *one* word 
... namely, "Vista". On my Vista box I have only msys-1.0.11. GMP-4.2.2 
fails in exactly the same way on Vista, msys-1.0.11 as it failed on XP, 
msys-1.0.11. But whereas GMP-4.2.1 also failed in exactly the same way on 
XP, msys-1.0.11, GMP-4.2.1 builds flawlessly on Vista, msys-1.0.11. So ... 
what's the difference between XP, msys-1.0.11 and Vista, msys-1.0.11 ? Well, 
the msys-1.0.11 on Vista incorporates Cesar Strauss's patches (which are 
what enable it to work on Vista).

Anyway - as I've said above, I've just posted to gmp-bugs. Let's see what 
they can come up with.

In other replies to my initial post both Earnie Boyd and Keith Marshall 
proposed that the test failures could just be a line-endings isue. That 
could be the case (and I'll probably be able to verify once I find out how 
to get diagnostics of the test failures). But if it was a line-endings 
issue, wouldn't that affect *static* builds in exactly the same way ?

Thanks for the replies.

Cheers,
Rob 

The words real and symlink were only thrown in there to distinguish them
from the "emulated symlinks" provided by Cygwin, nothing more.... sheesh

Rolf Ebert wrote:

> The question is: should stage1 already build all the files (e.g. crt2.o,
> libkernel32.a, etc.) or are the later stages supposed to find these
> files in /mingw/lib?

Those are part of mingw-runtime and w32api respectively.  They aren't
part of gcc, so why would any gcc stage build them?  For a native
bootstrap they should all be used from /mingw/lib for every stage.  Or
are you talking about a combined tree build?  In that case it will still
fail because of the chicken and egg problem.

Brian

On Sunday 24 February 2008 16:45, Hans Schmucker wrote:
> Does it make any difference here?

Yes, it does.  What you actually said was 

| if you simply need symlinks it might be interesting to know that nt 
| supports them natively...

which is just blatantly untrue, since 

| ...and these real symlinks...

are nothing of the sort, and 

| ...work with whatever you throw them at

applies *only* if "whatever you throw them at" happens to be a 
directory.    

> He only wants to link to directories...

This may be so, in this particular instance.  However, *real* symbolic 
links apply equally to files and directories, and your sweeping 
statement suggests that this feature is available on WinNT, which is 
not the case; (and even in the case of reparse points, what tool does 
Microsnot provide, AS A STANDARD OS COMPONENT, for creating them)?

What is available, as Earnie had already stated, is the "reparse point", 
(a.k.a. "junction").  By throwing your hat in the ring, to qualify this 
as a "symlink", serves no additional useful purpose, beyond an apparent 
attempt to "perpetuate the nonsense" that WinNT somehow provides a real 
symbolic link capability.

Regards,
Keith.

Chris Sutcliffe writes:
>So I'm now confused, if they are going to provide information for
>developers to use via MSDN, are we going to run in to an issue where
>some information is patented and we cannot use it for w32api?  

Information can't be patented, only inventions. 

>This is going to make it difficult in terms of what tell patch
>contributors is a valid source of information.

Microsoft's patents haven't changed, so I don't see how you could've
possibly come to this conclusion.  Why would it be more difficult today
to tell if a patch infringes on a patent than it was before?

In any case, as far these newly publically documented protocols are
concerned, the press release states that "Microsoft is providing
a covenant not to sue open source developers for development or
non-commercial distribution of implementations of these protocols."
So things should be easier for you, since now all you have to worry
about is whether w32api violates the rest of Microsoft's patents (or
any one elses).  Fortunately, since I don't think anything in w32api
rises to level of what could be described as an invention, that doesn't
seem likely.

					Ross Ridge

Does it make any difference here? He only wants to link to directories...

Brian Dessent schrieb:
> Rolf Ebert wrote:
> 
>> /k/Data/Development/gcc-cvs/build_native/./prev-gcc/xgcc
>> -B/k/Data/Development/gcc-cvs/
>> build_native/./prev-gcc/ -B/mingw/mingw32/bin/ -g -O2
>> -D__USE_MINGW_ACCESS   conftest.c  >&5
>> C:\Programme\msys_1.0\mingw\bin\ld.exe: crt2.o: No such file: No such
>> file or directory
>> collect2: ld returned 1 exit status
> 
> The "-B/mingw/mingw32/bin/" there implies that gcc expects to find its
> GCC_EXEC_PREFIX at $prefix/$target which is the default in the absense
> of a sysroot.  If you're using Cygwin as a build environment then you
> can fix this simply by creating the dir $prefix/$target/ which contains
> 3 symlinks for bin, include, and lib each pointing to ../bin,
> ../include, and ../lib resp.  You also might be able to solve this by
> configuring --with-sysroot=/mingw but a sysroot for a native compiler
> bootstrap strikes me as a fundamentally broken idea.

I consider both ideas (manually setting symlinks and providing 
--with-sysroot) as broken.  For the time being I solved it by copying 
the necessary files from /mingw/lib into the prev-gcc folder.

I don't think that -B/mingw/mingw32/bin is relevant for the discussion 
as my build path is also provided 
-B/k/Data/Development/gcc-cvs/build_native/./prev-gcc/
The question is: should stage1 already build all the files (e.g. crt2.o, 
libkernel32.a, etc.) or are the later stages supposed to find these 
files in /mingw/lib?

BTW, I am using msys as build environment (with access to some cygwin 
binaries that are broken on msys like tar)

    Rolf

Hans Schmucker wrote:

> i haven't read through the whole discussion, but if you simply need
> symlinks it might be interesting to know that nt supports them
> natively and these real symlinks work with whatever you throw them at:
> http://www.microsoft.com/technet/sysinternals/FileAndDisk/Junction.mspx

Sigh.  No.  Junctions are nothing like symlinks, don't perpetuate that
nonsense.  <http://article.gmane.org/gmane.comp.gnu.mingw.msys/4178>

Brian

i haven't read through the whole discussion, but if you simply need symlinks
it might be interesting to know that nt supports them natively and these
real symlinks work with whatever you throw them at:
http://www.microsoft.com/technet/sysinternals/FileAndDisk/Junction.mspx

Quoting Brian Dessent <br...@de...>:

> Brian Dessent wrote:
>
>> of a sysroot.  If you're using Cygwin as a build environment then you
>
> Er, duh, symlinks of course won't work for the xgcc.
>

Yep, thats where MSYS comes in handy.  It doesn't created .lnk files 
and uses a copy instead.  Could be enhanced to use reparse points for 
directories on NTFS as has been discussed.

Earnie