Thread overview | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
June 15, 2006 Relocating GDC | ||||
---|---|---|---|---|
| ||||
If you build GDC in say "/usr" or "/mingw", is it then possible to relocate the binaries and Phobos ? I was under the impression that it should be able to work the location of Phobos out from where the gdc binary was located, e.g. "../include/d/?.?.?/" but that does not seem to be the case it seems... I had hoped for the gdcmac/gdcwin binaries to be relocatable from the default /usr and C:\MinGW, but it seems that they can't find e.g. "object.d" unless you specifically tell it where to search ? And I was hoping to avoid having to set DFLAGS... --anders |
June 17, 2006 Re: Relocating GDC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | Anders F Björklund wrote: > > If you build GDC in say "/usr" or "/mingw", is it > then possible to relocate the binaries and Phobos ? > > I was under the impression that it should be able > to work the location of Phobos out from where the > gdc binary was located, e.g. "../include/d/?.?.?/" > but that does not seem to be the case it seems... > > > I had hoped for the gdcmac/gdcwin binaries to be > relocatable from the default /usr and C:\MinGW, > but it seems that they can't find e.g. "object.d" > unless you specifically tell it where to search ? Maybe you should look at MinGW source, because other languages work OK with relocation. -- |
June 18, 2006 Re: Relocating GDC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Khropov | Andrei Khropov wrote:
>>If you build GDC in say "/usr" or "/mingw", is it
>>then possible to relocate the binaries and Phobos ?
>
> Maybe you should look at MinGW source,
> because other languages work OK with relocation.
Actually I would be more likely to just take out
the "relocatable" flag / feature from the packages,
but if anyone else likes to do the work and tell
me what file to patch then I'll be happy to do it...
--anders
|
June 19, 2006 Re: Relocating GDC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | Anders F Björklund wrote:
>
> If you build GDC in say "/usr" or "/mingw", is it
> then possible to relocate the binaries and Phobos ?
>
> I was under the impression that it should be able
> to work the location of Phobos out from where the
> gdc binary was located, e.g. "../include/d/?.?.?/"
> but that does not seem to be the case it seems...
>
>
> I had hoped for the gdcmac/gdcwin binaries to be
> relocatable from the default /usr and C:\MinGW,
> but it seems that they can't find e.g. "object.d"
> unless you specifically tell it where to search ?
>
> And I was hoping to avoid having to set DFLAGS...
>
> --anders
I haven't figured this out completely, but here goes: To get relocation working under msys, the --prefix option must be the actual windows path and not the unix-style path. So, --prefix=c:/msys/1.0 would work, but --prefix=/usr would not.
For some reason, the compilers in the mingw distribution can be relocated even though they are configured with --prefix=/mingw. It might have something to do with the /mingw entry in /etc/fstab... I have not yet tried building with --prefix=/mingw. I have only tried other directories in the msys tree.
David
|
June 19, 2006 Re: Relocating GDC | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Friedman | David Friedman wrote: > I haven't figured this out completely, but here goes: To get relocation working under msys, the --prefix option must be the actual windows path and not the unix-style path. So, --prefix=c:/msys/1.0 would work, but --prefix=/usr would not. > > For some reason, the compilers in the mingw distribution can be relocated even though they are configured with --prefix=/mingw. It might have something to do with the /mingw entry in /etc/fstab... I have not yet tried building with --prefix=/mingw. I have only tried other directories in the msys tree. The MinGW compiler does not work for gdc though (because that is what I had used and it didn't relocate, even if their gcc/g++ does just fine?), so I think I will make a test with using --prefix=c:/mingw instead of the current --prefix=/mingw (that was taken from the default build.sh) Thanks for the idea, and let us know if you find their special trick :-) --anders PS. http://sf.net/tracker/index.php?func=detail&aid=1506841&group_id=168193&atid=845875 |
June 19, 2006 Re: Relocating GDC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | Anders F Björklund wrote: > The MinGW compiler does not work for gdc though (because that is what I had used and it didn't relocate, even if their gcc/g++ does just fine?) MinGW gcc/g++ work from nonstandard path (d:\Development\MinGW\) just fine on my machine (current version - 3.4.2). -- |
June 19, 2006 Re: Relocating GDC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Khropov | Andrei Khropov wrote:
>>The MinGW compiler does not work for gdc though (because that is what I had
>>used and it didn't relocate, even if their gcc/g++ does just fine?)
>
> MinGW gcc/g++ work from nonstandard path (d:\Development\MinGW\) just fine on
> my machine (current version - 3.4.2).
Yes it works OK for gcc/g++, but the same version doesn't work for gdc.
(so there must be a change in gcc/g++ includes, that isn't for Phobos?)
Changing prefix to "c:/mingw/" makes all my other scripts choke though.
DESTDIR doesn't take kindly to weird characters like colons in the path.
So the best fix here would be if GDC could understand --prefix=/mingw too, and be relocatable even after using that (just like the other GCC)
And we still need to come up with some fix for gdmd, so that you can call it like "gdmd" - without needing any "gdmd.pl" suffix nonsense...
--anders
|
June 19, 2006 Re: Relocating GDC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | I wrote:
And we still need to come up with some fix for gdmd, so that you can
> call it like "gdmd" - without needing any "gdmd.pl" suffix nonsense...
Phew, that was a whole lot simpler than I ever imagined: "pl2bat gdmd"
--anders
|
Copyright © 1999-2021 by the D Language Foundation