Re: setting environment variables
On Jul 30, 2008, at 19:06, Ryan Schmidt wrote:
> On Jul 30, 2008, at 18:49, Rainer Müller wrote:
>
>> Ryan Schmidt wrote:
>>
>>> It's still no, but for wine and mapm3, I installed a wrapper
>>> script to set needed environment variables. Check it out. I
>>> recommend the mechanism used by mapm3; I'll change the wine
>>> port's method to use mapm3's method soon. (Put the real binary in
>>> ${prefix}/lib/${name}/;
>>
>> Not really sure, but wouldn't be ${prefix}/libexec the more correct
>> place than ${prefix}/lib?
>>
>> porthier(7):
>> lib/ archive libraries
>> libexec/ system daemons & system utilities (executed by other pro-
>> grams)
>
> I had not looked at porthier, but I had looked at the FHS
> documentation which does not mention libexec, and an extended forum
> discussion argued against the use of libexec and for the use of lib
> for that reason. We are not following the FHS then?
>
> http://www.pathname.com/fhs/
The Guide also mentions libexec so that's what I should use. I
actually like the idea of separating hidden binaries from libraries,
but I didn't use it because the FHS is against it. But since Mac OS X
is not Linux and MacPorts doesn't follow the FHS, at least in this
regard, I changed the port to use libexec. Thanks for pointing me to
the right documentation!
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Valid platform variant string in libtheora port file?
Hello All --
I have recently written a script that parses numerous MacPorts and their
dependencies and variants information (in my collection of ports I use about
455 total). Of the total, I found one part, the libtheora port (version
1.0beta2), that produces an platform variant name of "darwin_9_i386", when
queried with the port command-line program, specifically:
$ port variants libtheora
libtheora has the variants:
universal
doc: Install extra documentation
*darwin_9_i386*
With all other ports I only see either "darwin_9" or "darwin_i386" or
"macosx" as specific strings representing platform variants, but haven't
seen and string combination akin to the libtheora port's creative
combination of "darwin_9_i386".
According to the MacPorts documentation, it does not appear that combining
darwin_9 and darwin_i386 into one string is legal:
http://guide.macports.org/#reference.variants.platform
Platform variants are either defined by default in MacPorts base, or defined
by a port author to customize a port's installation according to OS
(operating system) or hardware platform.
platform [os_platform] [hw_platform] [version] [arch]
However, looking inside the libtheora Portfile, I find:
*platform darwin 9 i386* {
# http://trac.macports.org/projects/macports/ticket/13033
configure.args-append --disable-asm
}
If anyone could shed some additional light on my observation, with regard
whether to the legitamacy of this port variant, that would be quite
appreciated.
Thanks,
T.M.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: setting environment variables
On Jul 30, 2008, at 18:49, Rainer Müller wrote:
> Ryan Schmidt wrote:
>
>> It's still no, but for wine and mapm3, I installed a wrapper
>> script to set needed environment variables. Check it out. I
>> recommend the mechanism used by mapm3; I'll change the wine
>> port's method to use mapm3's method soon. (Put the real binary in
>> ${prefix}/lib/${name}/;
>
> Not really sure, but wouldn't be ${prefix}/libexec the more correct
> place than ${prefix}/lib?
>
> porthier(7):
> lib/ archive libraries
> libexec/ system daemons & system utilities (executed by other pro-
> grams)
I had not looked at porthier, but I had looked at the FHS
documentation which does not mention libexec, and an extended forum
discussion argued against the use of libexec and for the use of lib
for that reason. We are not following the FHS then?
http://www.pathname.com/fhs/
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: setting environment variables
Ryan Schmidt wrote:
> It's still no, but for wine and mapm3, I installed a wrapper script
> to set needed environment variables. Check it out. I recommend the
> mechanism used by mapm3; I'll change the wine port's method to use
> mapm3's method soon. (Put the real binary in ${prefix}/lib/${name}/;
Not really sure, but wouldn't be ${prefix}/libexec the more correct
place than ${prefix}/lib?
porthier(7):
lib/ archive libraries
libexec/ system daemons & system utilities (executed by other pro-
grams)
Rainer
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Perl 5.8 build failing
On Jul 30, 2008, at 10:22, Randall Perry wrote: I'm getting the same error trying the 5.10 install. Can't find 'boot_File__Glob' symbol in lib/auto/File/Glob/Glob.bundle at lib/File/Glob.pm line 96 Verifed the file was there and the symbol was present: [xserve1:/opt/local] randy% grep boot_File__Glob /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_la ng_perl5.10/work/perl-5.10.0/lib/auto/File/Glob/Glob.bundle Binary file /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_la ng_perl5.10/work/perl-5.10.0/lib/auto/File/Glob/Glob.bundle matches Guess no one's got a fix yet? >>> >>> No fix. Last I heard someone was looking at it. They've changed >>> the >>> port files a couple of times: an upgrade tried to recompile >>> Perl. But >>> no luck. >> >> I don't know that anyone is looking at it, until we get more >> information. For example, I cannot reproduce the problem on my system >> so I cannot speculate about a fix. Take a look at the ticket and see >> if you can provide any more information, any hint about what might be >> different between your system and everyone else's where perl is >> installing just fine. For example, do you have anything in /usr/ >> local, >> which often causes problems for MacPorts? > > /usr/local is my standard install location. I only use macports when I > can't build from scratch. My default perl is in /usr/local/. Then that's probably the problem. We can't support installations where things are installed in /usr/local. It just causes lots of problems, as you're seeing. Sorry. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: setting environment variables
On Jul 30, 2008, at 06:25, Michael Thon wrote:
> The port of the ncbi_tools package would really benefit from having a
> couple of environment variables set for users at install time. When I
> took over the package I asked if there was a way for a Portfile to do
> this and the answer (at that time) was no. Maybe something has
> changed since?
It's still no, but for wine and mapm3, I installed a wrapper script
to set needed environment variables. Check it out. I recommend the
mechanism used by mapm3; I'll change the wine port's method to use
mapm3's method soon. (Put the real binary in ${prefix}/lib/${name}/;
put the wrapper in ${prefix}/bin/ and write it to cd to ${prefix}/lib/
${name}/ and run the real program with the same arguments.)
http://trac.macports.org/changeset/38699
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Perl 5.8 build failing
>>> >>> I'm getting the same error trying the 5.10 install. >>> Can't find 'boot_File__Glob' symbol in >>> lib/auto/File/Glob/Glob.bundle at >>> lib/File/Glob.pm line 96 >>> >>> >>> Verifed the file was there and the symbol was present: >>> [xserve1:/opt/local] randy% grep boot_File__Glob >>> >>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_perl5.10/work/perl-5.10.0/lib/auto/File/Glob/Glob.bundle >>> >>> >>> Binary file >>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_perl5.10/work/perl-5.10.0/lib/auto/File/Glob/Glob.bundle >>> >>> >>> matches >>> >>> Guess no one's got a fix yet? >> >> No fix. Last I heard someone was looking at it. They've changed the >> port files a couple of times: an upgrade tried to recompile Perl. But >> no luck. > > I don't know that anyone is looking at it, until we get more > information. For example, I cannot reproduce the problem on my system > so I cannot speculate about a fix. Take a look at the ticket and see > if you can provide any more information, any hint about what might be > different between your system and everyone else's where perl is > installing just fine. For example, do you have anything in /usr/local, > which often causes problems for MacPorts? /usr/local is my standard install location. I only use macports when I can't build from scratch. My default perl is in /usr/local/. -- Randall Perry sysTame Xserve Web Hosting/Co-location/Leasing QuickTime Streaming Mac Consulting/Sales http://www.systame.com/ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
setting environment variables
The port of the ncbi_tools package would really benefit from having a couple of environment variables set for users at install time. When I took over the package I asked if there was a way for a Portfile to do this and the answer (at that time) was no. Maybe something has changed since? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
