Automatic path translation....

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Automatic path translation....

Scott Neugroschl

Are there any plans at all to provide some kind of switch for automatic path translation (/usr, etc…)

 

I am using MinGW with Eclipse and a cross compilation toolset.  The problem is that I’m using autotools to generate makefiles,

so when paths are passed to it (using –DSOME_PATH=”/usr/…..”), they get translated.

 

I tried replacing the path with //usr\subdir\subdir, but then I ran into a different problem.  This is a makefile generated by autotools, and it creates target config files using sed, which doesn’t mangle paths.

 

So I can either use the /usr form, and get bad defines passed to my compiler, or use //usr\, and get my config file mangled.

 

An environment variable to control path mangling behavior would be incredibly useful.

 

 

---

Scott Neugroschl | XYPRO Technology Corporation

4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |

 


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Automatic path translation....

Eli Zaretskii
> From: Scott Neugroschl <[hidden email]>
> Date: Mon, 23 Feb 2015 20:09:34 +0000
>
> Are there any plans at all to provide some kind of switch for automatic path
> translation (/usr, etc…)
>
> I am using MinGW with Eclipse and a cross compilation toolset. The problem is
> that I’m using autotools to generate makefiles,
>
> so when paths are passed to it (using –DSOME_PATH=”/usr/…..”), they get
> translated.
>
> I tried replacing the path with //usr\subdir\subdir, but then I ran into a
> different problem. This is a makefile generated by autotools, and it creates
> target config files using sed, which doesn’t mangle paths.
>
> So I can either use the /usr form, and get bad defines passed to my compiler,
> or use //usr\, and get my config file mangled.
>
> An environment variable to control path mangling behavior would be incredibly
> useful.

This kind of translation is why MSYS was born.  It is unclear to me
whether you use it or not in this scenario.


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Automatic path translation....

Scott Neugroschl
In reply to this post by Scott Neugroschl
>From: Eli Zaretskii <[hidden email]>
>Date: Mon, 23 Feb 2015 22:57:35 +0200
>> From: Scott Neugroschl <[hidden email]>
>> Date: Mon, 23 Feb 2015 20:09:34 +0000
>>
>> Are there any plans at all to provide some kind of switch for
>> automatic path translation (/usr, etc?)
>>
>> I am using MinGW with Eclipse and a cross compilation toolset. The
>> problem is that I?m using autotools to generate makefiles,
>>
>> so when paths are passed to it (using ?DSOME_PATH=?/usr/?..?), they
>> get translated.
>>
>> I tried replacing the path with //usr\subdir\subdir, but then I ran
>> into a different problem. This is a makefile generated by autotools,
>> and it creates target config files using sed, which doesn?t mangle paths.
>>
>> So I can either use the /usr form, and get bad defines passed to my
>> compiler, or use //usr\, and get my config file mangled.
>>
>> An environment variable to control path mangling behavior would be
>> incredibly useful.
>
>This kind of translation is why MSYS was born.  It is unclear to me whether you use it or not in this scenario.
>

I'm afraid I don't understand your question.  Yes, that translation is great... if you're building binaries to run on a WINDOWS system!!!!

Let me clarify my situation.

1. I am doing cross-compiles for platform X.  Platform X's cross-compiler is a Win32 binary.
2. I am using Eclipse as an environment.  Platform X's plugin requires a POSIX environment, with MinGW/MSYS recommended.
3. I am cross compiling a program that generates its makefiles via autoconf
4. The configure script uses straight-up POSIX tools to generate the makefile and config.h.  Therefore no name mangling takes place when generating the makefile.
5. The makefile passes some paths via command line defines to the compiler, e.g.  -DTHIS_PATH=/usr/local/whatever
6. As stated in 1) above, the cross-compiler is a Win32 binary, not a MinGW binary, so name mangling takes place.
7. Thus, I get paths in my binary that look like C:/MinGW/usr/bin (which is NOT correct for Platform X).
8. If I use the "mangle-proof" version of the paths -- e.g. //usr\local\whatever -- Then in the makefile where there is some stuff passed to sed (which is a MinGW binary, and thus not subject ot name mangling), the 'mangle-proof' name is passed, rather than /usr/local/whatever.

Either way, I'm f***ed.   Allowing the user to control this name mangling behavior would seem to be an obvious choice.

I would modify the msys-1.0.dll library myself, but I'm not familiar with the source code, do not have the time to learn it, and my employer would not pay for me to do that.



------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Automatic path translation....

Eli Zaretskii
> From: Scott Neugroschl <[hidden email]>
> Date: Mon, 23 Feb 2015 22:22:45 +0000
>
> Let me clarify my situation.
>
> 1. I am doing cross-compiles for platform X.  Platform X's cross-compiler is a Win32 binary.
> 2. I am using Eclipse as an environment.  Platform X's plugin requires a POSIX environment, with MinGW/MSYS recommended.
> 3. I am cross compiling a program that generates its makefiles via autoconf
> 4. The configure script uses straight-up POSIX tools to generate the makefile and config.h.  Therefore no name mangling takes place when generating the makefile.
> 5. The makefile passes some paths via command line defines to the compiler, e.g.  -DTHIS_PATH=/usr/local/whatever
> 6. As stated in 1) above, the cross-compiler is a Win32 binary, not a MinGW binary, so name mangling takes place.
> 7. Thus, I get paths in my binary that look like C:/MinGW/usr/bin (which is NOT correct for Platform X).
> 8. If I use the "mangle-proof" version of the paths -- e.g. //usr\local\whatever -- Then in the makefile where there is some stuff passed to sed (which is a MinGW binary, and thus not subject ot name mangling), the 'mangle-proof' name is passed, rather than /usr/local/whatever.
>
> Either way, I'm f***ed.   Allowing the user to control this name mangling behavior would seem to be an obvious choice.

I don't think you will be able to solve this conundrum with such an
option, at least not reliably.

Instead, I suggest to patch the programs not to use the brain-dead
method of recording absolute installation directories at build time.
This produces binaries that cannot be relocated, let alone copied to
another machine.  It is usually a simple matter to add some
boilerplate code in a few strategic places that compute the
installation directories relative to the directory where the program
executable file was found.  This way, only the relative path is
recorded in the binary, while the prefix is computed at run time.

I think some recent versions of GNU gettext include functions that
will allow you to make the package "relocatable".  If not, it's a
simple matter to write such code yourself.

> I would modify the msys-1.0.dll library myself, but I'm not familiar with the source code, do not have the time to learn it, and my employer would not pay for me to do that.

I don't think modifying the MSYS DLL would help you, since you need 2
versions of it, one that mangles file names, the other that doesn't,
and mixing such DLLs in the same project is tricky at best.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Automatic path translation....

Earnie Boyd
In reply to this post by Scott Neugroschl
> -----Original Message-----
> From: Scott Neugroschl
>
> >From: Eli Zaretskii <[hidden email]>
> >Date: Mon, 23 Feb 2015 22:57:35 +0200
> >> From: Scott Neugroschl <[hidden email]>
> >> Date: Mon, 23 Feb 2015 20:09:34 +0000
> >>
> >> Are there any plans at all to provide some kind of switch for
> >> automatic path translation (/usr, etc?)
> >>
> >> I am using MinGW with Eclipse and a cross compilation toolset. The
> >> problem is that I?m using autotools to generate makefiles,
> >>
> >> so when paths are passed to it (using ?DSOME_PATH=?/usr/?..?), they
> >> get translated.
> >>
> >> I tried replacing the path with //usr\subdir\subdir, but then I ran
> >> into a different problem. This is a makefile generated by autotools,
> >> and it creates target config files using sed, which doesn?t mangle
paths.
> >>
> >> So I can either use the /usr form, and get bad defines passed to my
> >> compiler, or use //usr\, and get my config file mangled.
> >>
> >> An environment variable to control path mangling behavior would be
> >> incredibly useful.
> >
> >This kind of translation is why MSYS was born.  It is unclear to me
whether you
> use it or not in this scenario.
> >
>
> I'm afraid I don't understand your question.  Yes, that translation is
great... if
> you're building binaries to run on a WINDOWS system!!!!
>

Eli was stating the purpose of MSYS is to translate the POSIX environment to
the Windows environment so that the Windows programs can find the files on
the file system.  If your package is embedding hard coded paths via a
defined macro then something is wrong with the design of the package.  I
know many do but for portability it is better to leave the PATH declarations
to a configuration file.

> Let me clarify my situation.
>
> 1. I am doing cross-compiles for platform X.  Platform X's cross-compiler
is a
> Win32 binary.

You can use MSYS to do this assuming the layout of the cross platform is
common with the POSIX methods of doing the cross build.

> 2. I am using Eclipse as an environment.  Platform X's plugin requires a
POSIX
> environment, with MinGW/MSYS recommended.

I'm not a user of Eclipse and cannot know what the requirements of it is.

> 3. I am cross compiling a program that generates its makefiles via
autoconf

The very reason for the creation of MSYS.

> 4. The configure script uses straight-up POSIX tools to generate the
makefile and
> config.h.  Therefore no name mangling takes place when generating the
> makefile.

The generated files should use POSIX paths and the tools that understand
those paths.

> 5. The makefile passes some paths via command line defines to the
compiler,
> e.g.  -DTHIS_PATH=/usr/local/whatever

So when your Windows executable receives this MSYS does its translation
magic which is as designed.  I've already stated that this is a bad idea
because of portability across systems and also within a like system under a
different root.

> 6. As stated in 1) above, the cross- compiler is a Win32 binary, not a
MinGW binary, so name mangling takes place.

Not name mangling it is PATH resolution between two differing systems.

> 7. Thus, I get paths in my binary that look like C:/MinGW/usr/bin (which
is NOT
> correct for Platform X).

Well, it is correctly translated by MSYS which is a tool that translates
paths from POSIX to Windows for Windows native executables.

> 8. If I use the "mangle-proof" version of the paths -- e.g.
//usr\local\whatever --
> Then in the makefile where there is some stuff passed to sed (which is a
MinGW
> binary, and thus not subject ot name mangling), the 'mangle-proof' name is
> passed, rather than /usr/local/whatever.
>

I don't understand this.  If you use -DMY_MACRO=//usr/local/mypath then MSYS
simply removes the first / and passes that to the program.  Sed shouldn't be
needed.

--
Earnie


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Automatic path translation....

Earnie Boyd
In reply to this post by Scott Neugroschl
> From: Scott Neugroschl
>
> > I don't understand this.  If you use -DMY_MACRO=//usr/local/mypath
> > then MSYS simply removes the first / and passes that to the program.
Sed

> shouldn't be needed.
>
> Not quite:
>
> $ cat a.c
> FRED
> $ c89 -DFRED=/usr/local/fred -E a.c
> #line 1 "c:\\Users\\scott_n\\a.c"
> C:/MinGW/msys/1.0/local/fred
> $ c89 -DFRED=//usr/local/fred -E a.c
> #line 1 "c:\\Users\\scott_n\\a.c"
> / /usr/local/fred
> $ c89 -DFRED='//usr\local\fred' -E a.c
> #line 1 "c:\\Users\\scott_n\\a.c"
> /usr/local/fred
>
>
> Note that when I use //usr/local/fred I get a leading "/ " on the output.
> Only //usr\local\fred  gives the proper output.
>

You should report this in the bug tracker for MSYS.

--
Earnie


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe