Hi,
You can also do it with manifests. The example attached manifests allow
an executable in directory c:\bin to load libstdc++-6.dll and
libgcc_s_sjlj-1.dll from a subdirectory. Nothing is needed other than
the manifests. The subdirectory is not on the PATH.
The directory and file structure
On 2012-10-26 1:35 PM, Earnie Boyd wrote:
> On Fri, Oct 26, 2012 at 12:27 PM, Ruben Van Boxem
> wrote:
>>
>> Also, can someone clarify that you only need to be able to provider the
>> source when asked for it vs providing it in some public place, which might
>> not even be reachable everywhere in
> So I would like to get your opinion. You might have complete
> different opinion about planning mingw-w64's release-cycles, so don't
> hesitate to tell us what you think about this subject.
First, thanks for keeping the discussion open. It has been informative so far.
Second, as a consumer of
> Also, can someone clarify that you only need to be able to provider the
> source when asked for it vs providing it in some public place, which might
> not even be reachable everywhere in the world?
I think it'd be best if you provided the correct sources with your
builds of GCC, so that the en
On Fri, Oct 26, 2012 at 12:27 PM, Ruben Van Boxem
wrote:
>
> Also, can someone clarify that you only need to be able to provider the
> source when asked for it vs providing it in some public place, which might
> not even be reachable everywhere in the world?
AIUI, at least for v2 of the license,
Op 26 okt. 2012 18:10 schreef "Ray Donnelly" het
volgende:
>
> Ok, if this is all true, then IMHO, ideally the necessary sources
> would be included with every build (even binary) of mingw gcc, with a
> big README explaining these legal requirements.
See the COPYING* files in the source distribut
On Oct 26 12:05, Earnie Boyd wrote:
> On Fri, Oct 26, 2012 at 11:54 AM, Ray Donnelly wrote:
> > On Fri, Oct 26, 2012 at 4:38 PM, Corinna Vinschen wrote:
> >> On Oct 26 16:10, Ray Donnelly wrote:
> >>> I've never seen any precedent of anyone ever doing this anywhere.
> >>>
> >>> Are you saying we ar
Ok, if this is all true, then IMHO, ideally the necessary sources
would be included with every build (even binary) of mingw gcc, with a
big README explaining these legal requirements.
On Fri, Oct 26, 2012 at 5:05 PM, Earnie Boyd
wrote:
> On Fri, Oct 26, 2012 at 11:54 AM, Ray Donnelly wrote:
>> On
On Fri, Oct 26, 2012 at 11:54 AM, Ray Donnelly wrote:
> On Fri, Oct 26, 2012 at 4:38 PM, Corinna Vinschen wrote:
>> On Oct 26 16:10, Ray Donnelly wrote:
>>> I've never seen any precedent of anyone ever doing this anywhere.
>>>
>>> Are you saying we are all in violation here? If so, 'we' includes a
On Fri, Oct 26, 2012 at 11:39 AM, Ruben Van Boxem
wrote:
>
> I also don't think a static runtime link changes any of this, TDM. >From the
> same FAQ as before:
> "neither the GPL nor the GCC Runtime Library Exception distinguish between
> static linking, dynamic linking, and other methods for comb
On Fri, Oct 26, 2012 at 4:38 PM, Corinna Vinschen wrote:
> On Oct 26 16:10, Ray Donnelly wrote:
>> I've never seen any precedent of anyone ever doing this anywhere.
>>
>> Are you saying we are all in violation here? If so, 'we' includes a
>> huge amount of developers and applications (every Window
2012/10/26 Kai Tietz
> Yes, you have to take care to provide a link to source-code or the
> source itself of the gcc libraries with runtime-exception you are
> using. It is not enough to point to somebody else, which might
> provide the sources.
> Btw this is the cause why mingw-w64 always doe
On Oct 26 16:10, Ray Donnelly wrote:
> I've never seen any precedent of anyone ever doing this anywhere.
>
> Are you saying we are all in violation here? If so, 'we' includes a
> huge amount of developers and applications (every Windows C++
> application built with GCC!)
No, that's not the case.
2012/10/26 Алексей Павлов :
> Hi!
> Can I link program with shared library that not in PATH by relative path on
> windows? I have structure like below:
>
> ORIGIN
> |- bin
> | \-program.exe
> |- opt
> | |-lib
> | | \-mylib.dll
Yes, this is possible. But DLL loading mechanism wor
Yes, you have to take care to provide a link to source-code or the
source itself of the gcc libraries with runtime-exception you are
using. It is not enough to point to somebody else, which might
provide the sources.
Btw this is the cause why mingw-w64 always does binary and
source-package relea
Hi!
Can I link program with shared library that not in PATH by relative path on
windows? I have structure like below:
*ORIGIN
|- bin
| \-program.exe
|- opt
| |-lib
| | \-mylib.dll*
I try to add arguments to LDFLAGS
*Wl,-rpath,'../opt/lib' -L/path/to/lib -lmylib*
But without su
On 10/26/2012 6:52 AM, Earnie Boyd wrote:
> IANAL either but I am not spreading FUD. The exception covers the use
> and not the distribution. If you don't believe me ask Richard
> Stallman.
>
> http://www.gnu.org/licenses/gcc-exception-3.1-faq.html";>
> *snip*
> Note that if you distribute libstd
I've never seen any precedent of anyone ever doing this anywhere.
Are you saying we are all in violation here? If so, 'we' includes a
huge amount of developers and applications (every Windows C++
application built with GCC!)
On Fri, Oct 26, 2012 at 4:00 PM, Corinna Vinschen wrote:
> On Oct 26 15
On Oct 26 15:04, Ruben Van Boxem wrote:
> And that Section 6 clearly states you can point to e.g. the GCC website for
> the source code:
> http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites
No, you're misinterpreting that. Read again. *You* can provide the
sources of the GP
On Fri, Oct 26, 2012 at 9:04 AM, Ruben Van Boxem
wrote:
>
> And that Section 6 clearly states you can point to e.g. the GCC website for
> the source code:
> http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites
>
> So absolutely no end-developer hassle in providing toolchain sou
On 10/25/2012 17:17, JonY wrote:
> On 10/25/2012 15:04, Ruben Van Boxem wrote:
>> Currently, trunk has several new features, some of which have matured quite
>> a while ago (I'm looking at you, large file support for C streams). It also
>> has some more WIP stuff.
>>
>
> If any branching is going
2012/10/26 Earnie Boyd
> On Fri, Oct 26, 2012 at 8:05 AM, Ruben Van Boxem
> wrote:
> > 2012/10/26 Earnie Boyd
> >>
> >> On Thu, Oct 25, 2012 at 9:07 PM, JonY wrote:
> >> > Microsoft DLLs when possible, eg msvcrt.dll, though it is not possible
> >> > unless you stick strictly to C. Like Kai says
On Fri, Oct 26, 2012 at 8:05 AM, Ruben Van Boxem
wrote:
> 2012/10/26 Earnie Boyd
>>
>> On Thu, Oct 25, 2012 at 9:07 PM, JonY wrote:
>> > Microsoft DLLs when possible, eg msvcrt.dll, though it is not possible
>> > unless you stick strictly to C. Like Kai says, C++ support comes from
>> > GCC libst
2012/10/26 Earnie Boyd
> On Thu, Oct 25, 2012 at 9:07 PM, JonY wrote:
> > Microsoft DLLs when possible, eg msvcrt.dll, though it is not possible
> > unless you stick strictly to C. Like Kai says, C++ support comes from
> > GCC libstdc++, fortran support from libgfortran etc. You should have no
>
On Thu, Oct 25, 2012 at 9:07 PM, JonY wrote:
> Microsoft DLLs when possible, eg msvcrt.dll, though it is not possible
> unless you stick strictly to C. Like Kai says, C++ support comes from
> GCC libstdc++, fortran support from libgfortran etc. You should have no
> legal problems distributing these
The CLSIDs and IIDs for the classes and interfaces in the SAPI are
missing. In the Windows SDK they are contained as data in sapi.lib,
but I can't see them in libsapi.a.
I have attached a list of the CLSIDs and IIDs that are part of the
SAPI, with their corresponding GUID values (extracted from sa
26 matches
Mail list logo
