Smedley's build environment questions - OS2

This is a discussion on Smedley's build environment questions - OS2 ; Over the years I have made several attempts to get a well-functioning GCC build environment working. These attempts have met varying levels of success. Various recent threads on these newsgroups (regarding the Mozilla build env, the possibility of support for ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Smedley's build environment questions

  1. Smedley's build environment questions

    Over the years I have made several attempts to get a well-functioning
    GCC build environment working. These attempts have met varying levels
    of success. Various recent threads on these newsgroups (regarding the
    Mozilla build env, the possibility of support for GCC 3.4.x, etc.)
    have revived my interest in this.

    I have downloaded Paul Smedley's build environment and I have unzipped
    it onto an otherwise empty U: drive and I have followed the
    instructions regarding running makeomflibs and setting up an icon. Now
    I have many questions:

    1) Is this the best forum for such questions? Or are others which may
    also be helpful?

    2) The web page only refers to running MAKEOMFLIBS in the extras\lib
    directory while the readme says to do this in both extras\lib and
    usr\lib. Which is correct?

    3) Since I unzipped to the U: drive, are there any adjustments which
    need to be made to set up the build environment correctly? I ask
    because...
    a) My global environment does not set EMX, GLIB, LIBIDL, TOOLKIT,
    AUTOCONF and VACPP365. GCC335.CMD proceeds to set these to default but
    non-existant directories/files. Is this OK? Or should some or all of
    these have valid settings?
    b) GCC335.CMD sets some other variables in ways that lead to
    questions about their correctness:
    i) TERMCAP, GLIB_CONFIG and LIBIDL_CONFIG: Are set to point to
    non-existant directories/files because of the errors in environment
    variables due to (a) above.
    ii) TERM: Is not set. Why TERMCAP but not TERM?
    iii) LIB: Uses forward slashes on the first directory and
    backslashes on the rest??
    c) U:\moztools\config.site-gcc335b4 has a number of hard-coded
    paths. Which ones, if any, need to be corrected to point to actual
    files/directories before the "environment" is minimally correct?
    d) Are there restrictions on the paths used in these vraious
    settings?
    i) Which need to be on the same drive (i.e. U? And which can
    be on other drives?
    ii) Which must not have a drive letter and colon?
    iii) Which need forward slashes, which need backslashes, which
    don't care and is it ever OK to have some of each (See b.iii above)?

    4) Is there a test package somewhere which I could try to build which
    is "basic" enough to test the essential functionality of Paul's build
    environment? I have tried (and failed) builds of less-381 and
    pcre-6.7.
    Less-381 almost builds (there is a problem with "___open" :
    unresolved external).
    The pcre-6.7 fails with "LIBTOOL@: Can't open LIBTOOL@", which I
    assume means I need libtool. (Is this a symptom of a flaw in the
    environment?)

    5) Some packages come with a makefile purported to be the makefile for
    OS/2 (makefile.o2e). But they seem to be quite old in comparison to
    the dates of the source files. Are these worth trying?

    These are but a few of the questions I have. Thanks for reading this
    far and thanks for any help you can provide!

    --

    John Small


  2. Re: Smedley's build environment questions

    On Wed, 24 Sep 2008 18:46:07 UTC, "John Small"
    wrote:

    > Over the years I have made several attempts to get a well-functioning
    > GCC build environment working. These attempts have met varying levels
    > of success. Various recent threads on these newsgroups (regarding the
    > Mozilla build env, the possibility of support for GCC 3.4.x, etc.)
    > have revived my interest in this.
    >
    > I have downloaded Paul Smedley's build environment and I have unzipped
    > it onto an otherwise empty U: drive and I have followed the
    > instructions regarding running makeomflibs and setting up an icon. Now
    > I have many questions:
    >
    > 1) Is this the best forum for such questions? Or are others which may
    > also be helpful?


    I think this is a good place. You, Dave Yeo, Paul and I are actually
    active users of Paul's BE.

    > 2) The web page only refers to running MAKEOMFLIBS in the extras\lib
    > directory while the readme says to do this in both extras\lib and
    > usr\lib. Which is correct?


    IIRC, I used makeomflibs in both directories, and worked fine.

    > 3) Since I unzipped to the U: drive, are there any adjustments which
    > need to be made to set up the build environment correctly? I ask
    > because...
    > a) My global environment does not set EMX, GLIB, LIBIDL, TOOLKIT,
    > AUTOCONF and VACPP365. GCC335.CMD proceeds to set these to default but
    > non-existant directories/files. Is this OK? Or should some or all of
    > these have valid settings?


    You don't need vac365. gcc335.cmd should set everything based on the
    directory structure made into the BE. Also, a good suggestion I got
    from Dave is to install the BE in a separate drive, while other
    environments (namely old GCC/EMX versions) should go into another
    unit.

    > b) GCC335.CMD sets some other variables in ways that lead to
    > questions about their correctness:
    > i) TERMCAP, GLIB_CONFIG and LIBIDL_CONFIG: Are set to point to
    > non-existant directories/files because of the errors in environment
    > variables due to (a) above.
    > ii) TERM: Is not set. Why TERMCAP but not TERM?
    > iii) LIB: Uses forward slashes on the first directory and
    > backslashes on the rest??


    Dunno about these two. I don't notice problems with LIB.

    > c) U:\moztools\config.site-gcc335b4 has a number of hard-coded
    > paths. Which ones, if any, need to be corrected to point to actual
    > files/directories before the "environment" is minimally correct?


    I only had some little trouble with Perl location, which I installed
    in U: as part of Paul's BE, while gcc335.cmd keeps on pointing to E:/.
    Just modifiyng those references did the job, and now it works like a
    charm.

    > d) Are there restrictions on the paths used in these vraious
    > settings?
    > i) Which need to be on the same drive (i.e. U? And which can
    > be on other drives?
    > ii) Which must not have a drive letter and colon?
    > iii) Which need forward slashes, which need backslashes, which
    > don't care and is it ever OK to have some of each (See b.iii above)?


    It should be enough to install it, unzip and run emxomflibs. Just
    correct the wrong references to Perl and you're done.

    All in all, it should be almost always a matter of "sh ./configure -
    make - make install", but it's not always the case. A good starting
    point is setting PWD to the directory you are working in.

    > 4) Is there a test package somewhere which I could try to build which
    > is "basic" enough to test the essential functionality of Paul's build
    > environment? I have tried (and failed) builds of less-381 and
    > pcre-6.7.
    > Less-381 almost builds (there is a problem with "___open" :
    > unresolved external).
    > The pcre-6.7 fails with "LIBTOOL@: Can't open LIBTOOL@", which I
    > assume means I need libtool. (Is this a symptom of a flaw in the
    > environment?)


    Did you run sh ./configure? It seems that the configuration went bad.

    > 5) Some packages come with a makefile purported to be the makefile for
    > OS/2 (makefile.o2e). But they seem to be quite old in comparison to
    > the dates of the source files. Are these worth trying?


    Seems it's a job for EMX/ older GCC releases. Try to "make" against
    those makefiles and report here.

    > These are but a few of the questions I have. Thanks for reading this
    > far and thanks for any help you can provide!


    Good luck, don't forget to keep us informed.

    Mentore

  3. Re: Smedley's build environment questions

    I haven't looked at Paul's build environment but will try to answer the
    more generic questions. (Mentore also has some good answers)

    On 09/24/08 11:46 am, John Small wrote:
    > Over the years I have made several attempts to get a well-functioning
    > GCC build environment working. These attempts have met varying levels
    > of success. Various recent threads on these newsgroups (regarding the
    > Mozilla build env, the possibility of support for GCC 3.4.x, etc.)
    > have revived my interest in this.
    >
    > I have downloaded Paul Smedley's build environment and I have unzipped
    > it onto an otherwise empty U: drive and I have followed the
    > instructions regarding running makeomflibs and setting up an icon. Now
    > I have many questions:
    >
    > 1) Is this the best forum for such questions? Or are others which may
    > also be helpful?


    The other place where discussion happens sometimes is the libc users list.

    >
    > 2) The web page only refers to running MAKEOMFLIBS in the extras\lib
    > directory while the readme says to do this in both extras\lib and
    > usr\lib. Which is correct?


    You should run it where ever there are libs with the suffix of .a but
    not .lib. It will create the OMF libs ending with .lib.

    >
    > 3) Since I unzipped to the U: drive, are there any adjustments which
    > need to be made to set up the build environment correctly? I ask
    > because...
    > a) My global environment does not set EMX, GLIB, LIBIDL, TOOLKIT,
    > AUTOCONF and VACPP365. GCC335.CMD proceeds to set these to default but
    > non-existant directories/files. Is this OK? Or should some or all of
    > these have valid settings?


    These all seem like settings for building Mozilla. If you have any of
    these installed then you should adjust the set commands. If not probably
    just leave them alone for now.

    > b) GCC335.CMD sets some other variables in ways that lead to
    > questions about their correctness:
    > i) TERMCAP, GLIB_CONFIG and LIBIDL_CONFIG: Are set to point to
    > non-existant directories/files because of the errors in environment
    > variables due to (a) above.
    > ii) TERM: Is not set. Why TERMCAP but not TERM?


    Perhaps Paul has not had any need for TERM. You can always add it.
    Once again I think the GLIB and LIBIDL config settings are for Mozilla.
    You can always install them later. See the build instructions on Mozilla.org

    > iii) LIB: Uses forward slashes on the first directory and
    > backslashes on the rest??


    IIRC LIB is only used by VACC. I'd think it should be backslashes but
    quite likely doesn't matter

    > c) U:\moztools\config.site-gcc335b4 has a number of hard-coded
    > paths. Which ones, if any, need to be corrected to point to actual
    > files/directories before the "environment" is minimally correct?


    If any of the hardcoded paths are wrong then they should be adjusted.
    You should use regular slashes in config.site. Is that config.site even
    used by anything? Configure finds config.site in $PREFIX/share or by
    looking at %CONFIG_SITE%

    > d) Are there restrictions on the paths used in these vraious
    > settings?
    > i) Which need to be on the same drive (i.e. U? And which can
    > be on other drives?
    > ii) Which must not have a drive letter and colon?


    Generally it is best if they are on the same drive. Some ports use
    %UNIXROOT% to find themselves and can be on different drives. Other
    ports understand drive letters or it doesn't matter. Some don't
    understand drive letters. I'd guess that Paul has already figurered it
    out correctly but you can experiment.

    > ii

    i) Which need forward slashes, which need backslashes, which
    > don't care and is it ever OK to have some of each (See b.iii above)?


    While a lot of ports don't care about the slashes and will work with a
    mix it is generally better to use normal slashes.

    >
    > 4) Is there a test package somewhere which I could try to build which
    > is "basic" enough to test the essential functionality of Paul's build
    > environment? I have tried (and failed) builds of less-381 and
    > pcre-6.7.
    > Less-381 almost builds (there is a problem with "___open" :
    > unresolved external).


    IIRC there is a _open that needs to be changed to open or maybe __open
    that needs to be changed to _open

    > The pcre-6.7 fails with "LIBTOOL@: Can't open LIBTOOL@", which I
    > assume means I need libtool. (Is this a symptom of a flaw in the
    > environment?)


    Did configure create libtool?

    >
    > 5) Some packages come with a makefile purported to be the makefile for
    > OS/2 (makefile.o2e). But they seem to be quite old in comparison to
    > the dates of the source files. Are these worth trying?


    Sometimes they are. If you look at makefile.o2e you will see that only a
    couple of changes are needed before trying.
    O = obj changed to O = o
    and the LIBS line commented out. Then you could try it. KLIBC is kind of
    another version of EMX so sometimes the old makefiles work fine with
    only minor editing.
    Don't forget about the defines.o2 file

    >
    > These are but a few of the questions I have. Thanks for reading this
    > far and thanks for any help you can provide!
    >


    Dave

  4. Re: Smedley's build environment questions

    On Wed, 24 Sep 2008 21:15:17 UTC, "Mentore Siesto"
    wrote:

    > On Wed, 24 Sep 2008 18:46:07 UTC, "John Small"
    > wrote:
    >
    > You don't need vac365. gcc335.cmd should set everything based on the
    > directory structure made into the BE. Also, a good suggestion I got
    > from Dave is to install the BE in a separate drive, while other
    > environments (namely old GCC/EMX versions) should go into another
    > unit.


    I installed to an empty U: drive.

    > > c) U:\moztools\config.site-gcc335b4 has a number of hard-coded
    > > paths. Which ones, if any, need to be corrected to point to actual
    > > files/directories before the "environment" is minimally correct?

    >
    > I only had some little trouble with Perl location, which I installed
    > in U: as part of Paul's BE, while gcc335.cmd keeps on pointing to E:/.
    > Just modifiyng those references did the job, and now it works like a
    > charm.


    In my BE it is not gcc335.cmd but u:/moztools/config.site-gcc335b4
    that has references to e:/perl. I have already correct these (and
    other paths for items I actually have).

    Is there a reference somewhere that explains the contents of
    %CONFIG_SITE% file?

    > All in all, it should be almost always a matter of "sh ./configure -
    > make - make install", but it's not always the case. A good starting
    > point is setting PWD to the directory you are working in.


    Are you talking about an environment variable named PWD?

    > > 4) Is there a test package somewhere which I could try to build which
    > > is "basic" enough to test the essential functionality of Paul's build
    > > environment? I have tried (and failed) builds of less-381 and
    > > pcre-6.7.
    > > Less-381 almost builds (there is a problem with "___open" :
    > > unresolved external).
    > > The pcre-6.7 fails with "LIBTOOL@: Can't open LIBTOOL@", which I
    > > assume means I need libtool. (Is this a symptom of a flaw in the
    > > environment?)

    >
    > Did you run sh ./configure? It seems that the configuration went bad.


    I ran ash ./configure as suggested by Paul (web site and readme).
    Should I use sh instead?

    --

    John Small


  5. Re: Smedley's build environment questions

    On Thu, 25 Sep 2008 03:15:02 UTC, Dave Yeo
    wrote:

    > I haven't looked at Paul's build environment but will try to answer the
    > more generic questions.


    Thank you!

    > > 2) The web page only refers to running MAKEOMFLIBS in the extras\lib
    > > directory while the readme says to do this in both extras\lib and
    > > usr\lib. Which is correct?

    >
    > You should run it where ever there are libs with the suffix of .a but
    > not .lib. It will create the OMF libs ending with .lib.


    Will do. I've found that there are two different makeomflibs(?), one
    in extras/lib and another in usr/lib. The one in extras/lib is less
    hard-coded to the directory it is in.

    Would it be OK to write a makeomflibs.cmd which simply processes,
    recursively, every *.a file it finds statring from either the current
    directory or a directory that is passed to it? Neither one of the
    existing programs do this.

    > > 3) Since I unzipped to the U: drive, are there any adjustments which
    > > need to be made to set up the build environment correctly? I ask
    > > because...
    > > a) My global environment does not set EMX, GLIB, LIBIDL, TOOLKIT,
    > > AUTOCONF and VACPP365. GCC335.CMD proceeds to set these to default but
    > > non-existant directories/files. Is this OK? Or should some or all of
    > > these have valid settings?

    >
    > These all seem like settings for building Mozilla. If you have any of
    > these installed then you should adjust the set commands. If not probably
    > just leave them alone for now.
    >
    > > b) GCC335.CMD sets some other variables in ways that lead to
    > > questions about their correctness:
    > > i) TERMCAP, GLIB_CONFIG and LIBIDL_CONFIG: Are set to point to
    > > non-existant directories/files because of the errors in environment
    > > variables due to (a) above.
    > > ii) TERM: Is not set. Why TERMCAP but not TERM?

    >
    > Perhaps Paul has not had any need for TERM. You can always add it.
    > Once again I think the GLIB and LIBIDL config settings are for Mozilla.
    > You can always install them later. See the build instructions on Mozilla.org
    >
    > > iii) LIB: Uses forward slashes on the first directory and
    > > backslashes on the rest??

    >
    > IIRC LIB is only used by VACC. I'd think it should be backslashes but
    > quite likely doesn't matter
    >
    > > c) U:\moztools\config.site-gcc335b4 has a number of hard-coded
    > > paths. Which ones, if any, need to be corrected to point to actual
    > > files/directories before the "environment" is minimally correct?

    >
    > If any of the hardcoded paths are wrong then they should be adjusted.
    > You should use regular slashes in config.site. Is that config.site even
    > used by anything? Configure finds config.site in $PREFIX/share or by
    > looking at %CONFIG_SITE%


    GCC335.CMD sets %CONFIG_SITE% to point to
    U:\moztools\config.site-gcc335b4. Whenever I run ash ./configure the
    first lines output are:

    loading site script u:/moztools/config.site-gcc335b4
    type: No such file or directory
    type: No such file or directory
    type: No such file or directory
    type: No such file or directory
    function: No such file or directory
    builtin: No such file or directory

    Do these "no such" messages indicate errors which need to be
    corrected?

    > > 4) Is there a test package somewhere which I could try to build which
    > > is "basic" enough to test the essential functionality of Paul's build
    > > environment? I have tried (and failed) builds of less-381 and
    > > pcre-6.7.
    > > Less-381 almost builds (there is a problem with "___open" :
    > > unresolved external).

    >
    > IIRC there is a _open that needs to be changed to open or maybe __open
    > that needs to be changed to _open


    Actually I had already tried this. However, while the build does
    succeed this way, the built LESS does not behave the way I am used to:
    I have to press the ENTER key to get it to respond to any command!? (I
    can't imagine this is an "improvement". I think it must be the call to
    open/_open/__open/___open is not correct.)

    > > The pcre-6.7 fails with "LIBTOOL@: Can't open LIBTOOL@", which I
    > > assume means I need libtool. (Is this a symptom of a flaw in the
    > > environment?)

    >
    > Did configure create libtool?


    Is this a file, a directory or an env variable? If a file or
    directory, where should I look for it? (There is no such file in the
    build directory.)

    When ./configure is run I get the following:
    AC_LIBTOOL_WIN32_DLL: not found
    AC_PROG_LIBTOOL: not found

    Are these messages an indication why no libtool is built? Are they a
    sign that my build environment is incomplete/incorrect?

    --

    John Small


  6. Re: Smedley's build environment questions

    On 09/25/08 04:58 am, John Small wrote:
    > On Thu, 25 Sep 2008 03:15:02 UTC, Dave Yeo
    > wrote:
    >
    >> I haven't looked at Paul's build environment but will try to answer the
    >> more generic questions.

    >
    > Thank you!
    >
    >>> 2) The web page only refers to running MAKEOMFLIBS in the extras\lib
    >>> directory while the readme says to do this in both extras\lib and
    >>> usr\lib. Which is correct?

    >> You should run it where ever there are libs with the suffix of .a but
    >> not .lib. It will create the OMF libs ending with .lib.

    >
    > Will do. I've found that there are two different makeomflibs(?), one
    > in extras/lib and another in usr/lib. The one in extras/lib is less
    > hard-coded to the directory it is in.
    >
    > Would it be OK to write a makeomflibs.cmd which simply processes,
    > recursively, every *.a file it finds statring from either the current
    > directory or a directory that is passed to it? Neither one of the
    > existing programs do this.


    You could do this. I should point out that the recent GCC's can do on
    the fly conversion of libraries (and objects) so it isn't as important
    to convert them as it used to be.

    >
    >>> 3) Since I unzipped to the U: drive, are there any adjustments which
    >>> need to be made to set up the build environment correctly? I ask
    >>> because...
    >>> a) My global environment does not set EMX, GLIB, LIBIDL, TOOLKIT,
    >>> AUTOCONF and VACPP365. GCC335.CMD proceeds to set these to default but
    >>> non-existant directories/files. Is this OK? Or should some or all of
    >>> these have valid settings?

    >> These all seem like settings for building Mozilla. If you have any of
    >> these installed then you should adjust the set commands. If not probably
    >> just leave them alone for now.
    >>
    >>> b) GCC335.CMD sets some other variables in ways that lead to
    >>> questions about their correctness:
    >>> i) TERMCAP, GLIB_CONFIG and LIBIDL_CONFIG: Are set to point to
    >>> non-existant directories/files because of the errors in environment
    >>> variables due to (a) above.
    >>> ii) TERM: Is not set. Why TERMCAP but not TERM?

    >> Perhaps Paul has not had any need for TERM. You can always add it.
    >> Once again I think the GLIB and LIBIDL config settings are for Mozilla.
    >> You can always install them later. See the build instructions on Mozilla.org
    >>
    >>> iii) LIB: Uses forward slashes on the first directory and
    >>> backslashes on the rest??

    >> IIRC LIB is only used by VACC. I'd think it should be backslashes but
    >> quite likely doesn't matter
    >>
    >>> c) U:\moztools\config.site-gcc335b4 has a number of hard-coded
    >>> paths. Which ones, if any, need to be corrected to point to actual
    >>> files/directories before the "environment" is minimally correct?

    >> If any of the hardcoded paths are wrong then they should be adjusted.
    >> You should use regular slashes in config.site. Is that config.site even
    >> used by anything? Configure finds config.site in $PREFIX/share or by
    >> looking at %CONFIG_SITE%

    >
    > GCC335.CMD sets %CONFIG_SITE% to point to
    > U:\moztools\config.site-gcc335b4. Whenever I run ash ./configure the
    > first lines output are:
    >
    > loading site script u:/moztools/config.site-gcc335b4
    > type: No such file or directory
    > type: No such file or directory
    > type: No such file or directory
    > type: No such file or directory
    > function: No such file or directory
    > builtin: No such file or directory
    >
    > Do these "no such" messages indicate errors which need to be
    > corrected?


    They look familiar but I can't remember what causes them. I don't think
    they should be there.

    >
    >>> 4) Is there a test package somewhere which I could try to build which
    >>> is "basic" enough to test the essential functionality of Paul's build
    >>> environment? I have tried (and failed) builds of less-381 and
    >>> pcre-6.7.
    >>> Less-381 almost builds (there is a problem with "___open" :
    >>> unresolved external).

    >> IIRC there is a _open that needs to be changed to open or maybe __open
    >> that needs to be changed to _open

    >
    > Actually I had already tried this. However, while the build does
    > succeed this way, the built LESS does not behave the way I am used to:
    > I have to press the ENTER key to get it to respond to any command!? (I
    > can't imagine this is an "improvement". I think it must be the call to
    > open/_open/__open/___open is not correct.)


    I built less-424, which built out of the box. It has the same issue with
    input. Haven't looked closer but something needs adjusting for OS/2.

    >
    >>> The pcre-6.7 fails with "LIBTOOL@: Can't open LIBTOOL@", which I
    >>> assume means I need libtool. (Is this a symptom of a flaw in the
    >>> environment?)

    >> Did configure create libtool?

    >
    > Is this a file, a directory or an env variable? If a file or
    > directory, where should I look for it? (There is no such file in the
    > build directory.)


    libtool is both a package and a script that configure creates, usually
    in the same directory as configure. It is created with a program called
    ltmain.sh which should also be in the same directory as configure. In
    your bin (/usr/bin ?) there should also be libtool and libtoolize scripts.

    >
    > When ./configure is run I get the following:
    > AC_LIBTOOL_WIN32_DLL: not found
    > AC_PROG_LIBTOOL: not found
    >
    > Are these messages an indication why no libtool is built? Are they a
    > sign that my build environment is incomplete/incorrect?
    >


    Sounds like the M4 macros that libtool installs are not installed which
    doesn't seem right. There was a fairly new version of libtool recently
    uploaded to Hobbes you might want to look for it.
    Dave

  7. Re: Smedley's build environment questions

    On Thu, 25 Sep 2008 14:54:56 UTC, Dave Yeo
    wrote:

    > On 09/25/08 04:58 am, John Small wrote:
    > > On Thu, 25 Sep 2008 03:15:02 UTC, Dave Yeo
    > > wrote:


    > >>> c) U:\moztools\config.site-gcc335b4 has a number of hard-coded
    > >>> paths. Which ones, if any, need to be corrected to point to actual
    > >>> files/directories before the "environment" is minimally correct?
    > >> If any of the hardcoded paths are wrong then they should be adjusted.
    > >> You should use regular slashes in config.site. Is that config.site even
    > >> used by anything? Configure finds config.site in $PREFIX/share or by
    > >> looking at %CONFIG_SITE%

    > >
    > > GCC335.CMD sets %CONFIG_SITE% to point to
    > > U:\moztools\config.site-gcc335b4. Whenever I run ash ./configure the
    > > first lines output are:
    > >
    > > loading site script u:/moztools/config.site-gcc335b4
    > > type: No such file or directory
    > > type: No such file or directory
    > > type: No such file or directory
    > > type: No such file or directory
    > > function: No such file or directory
    > > builtin: No such file or directory
    > >
    > > Do these "no such" messages indicate errors which need to be
    > > corrected?

    >
    > They look familiar but I can't remember what causes them. I don't think
    > they should be there.
    >
    > >
    > >>> 4) Is there a test package somewhere which I could try to build which
    > >>> is "basic" enough to test the essential functionality of Paul's build
    > >>> environment? I have tried (and failed) builds of less-381 and
    > >>> pcre-6.7.
    > >>> Less-381 almost builds (there is a problem with "___open" :
    > >>> unresolved external).
    > >> IIRC there is a _open that needs to be changed to open or maybe __open
    > >> that needs to be changed to _open

    > >
    > > Actually I had already tried this. However, while the build does
    > > succeed this way, the built LESS does not behave the way I am used to:
    > > I have to press the ENTER key to get it to respond to any command!? (I
    > > can't imagine this is an "improvement". I think it must be the call to
    > > open/_open/__open/___open is not correct.)

    >
    > I built less-424, which built out of the box. It has the same issue with
    > input. Haven't looked closer but something needs adjusting for OS/2.
    >
    > >
    > >>> The pcre-6.7 fails with "LIBTOOL@: Can't open LIBTOOL@", which I
    > >>> assume means I need libtool. (Is this a symptom of a flaw in the
    > >>> environment?)
    > >> Did configure create libtool?

    > >
    > > Is this a file, a directory or an env variable? If a file or
    > > directory, where should I look for it? (There is no such file in the
    > > build directory.)

    >
    > libtool is both a package and a script that configure creates, usually
    > in the same directory as configure. It is created with a program called
    > ltmain.sh which should also be in the same directory as configure.


    There is such a file in the directory with configure.

    > In
    > your bin (/usr/bin ?) there should also be libtool and libtoolize scripts.


    I found them in /usr/local/bin which is, FWIW, on the PATH.

    > >
    > > When ./configure is run I get the following:
    > > AC_LIBTOOL_WIN32_DLL: not found
    > > AC_PROG_LIBTOOL: not found
    > >
    > > Are these messages an indication why no libtool is built? Are they a
    > > sign that my build environment is incomplete/incorrect?
    > >

    >
    > Sounds like the M4 macros that libtool installs are not installed which
    > doesn't seem right. There was a fairly new version of libtool recently
    > uploaded to Hobbes you might want to look for it.


    I had not previously installed libtool. So does this mean the "M4
    macros" are not right in Paul's build environment??

    I have downloaded libtool-1.5.26.zip. I will install it and give it a
    try.

    Thanks again for your help!

    --

    John Small


  8. Re: Smedley's build environment questions

    On 09/25/08 09:47 am, John Small wrote:
    >> In
    >> > your bin (/usr/bin ?) there should also be libtool and libtoolize scripts.

    >
    > I found them in /usr/local/bin which is, FWIW, on the PATH.
    >
    >>> > >
    >>> > > When ./configure is run I get the following:
    >>> > > AC_LIBTOOL_WIN32_DLL: not found
    >>> > > AC_PROG_LIBTOOL: not found
    >>> > >
    >>> > > Are these messages an indication why no libtool is built? Are they a
    >>> > > sign that my build environment is incomplete/incorrect?
    >>> > >
    >> >
    >> > Sounds like the M4 macros that libtool installs are not installed which
    >> > doesn't seem right. There was a fairly new version of libtool recently
    >> > uploaded to Hobbes you might want to look for it.

    >
    > I had not previously installed libtool. So does this mean the "M4
    > macros" are not right in Paul's build environment??


    Actually you might just need to run aclocal in the same directory as
    configure, probably
    ash aclocal -I. (note that is a dot after the I, means include current
    directory)
    Dave
    >
    > I have downloaded libtool-1.5.26.zip. I will install it and give it a
    > try.
    >
    > Thanks again for your help!
    >



  9. Re: Smedley's build environment questions

    On 09/25/08 04:58 am, John Small wrote:
    >> Did you run sh ./configure? It seems that the configuration went bad.

    >
    > I ran ash ./configure as suggested by Paul (web site and readme).
    > Should I use sh instead?


    Generally ash = sh though the odd script fails with ash eg FFmpeg needs
    %PWD% set to the current directory. The FFmpeg people claim that ash is
    broken in this regard but who knows.
    Also some scripts expect bash and fail with ash or pdksh, usual error I
    see is using == instead of =
    Dave

  10. Re: Smedley's build environment questions

    On Thu, 25 Sep 2008 23:46:32 UTC, Dave Yeo
    wrote:

    > On 09/25/08 09:47 am, John Small wrote:
    > >> In
    > >> > your bin (/usr/bin ?) there should also be libtool and libtoolize scripts.

    > >
    > > I found them in /usr/local/bin which is, FWIW, on the PATH.
    > >
    > >>> > >
    > >>> > > When ./configure is run I get the following:
    > >>> > > AC_LIBTOOL_WIN32_DLL: not found
    > >>> > > AC_PROG_LIBTOOL: not found
    > >>> > >
    > >>> > > Are these messages an indication why no libtool is built? Are they a
    > >>> > > sign that my build environment is incomplete/incorrect?
    > >>> > >
    > >> >
    > >> > Sounds like the M4 macros that libtool installs are not installed which
    > >> > doesn't seem right. There was a fairly new version of libtool recently
    > >> > uploaded to Hobbes you might want to look for it.

    > >
    > > I had not previously installed libtool. So does this mean the "M4
    > > macros" are not right in Paul's build environment??

    >
    > Actually you might just need to run aclocal in the same directory as
    > configure, probably
    > ash aclocal -I. (note that is a dot after the I, means include current
    > directory)


    The command as you gave it resulted in:
    aclocal: Can't open aclocal

    I found an aclocal file in /usr/bin which is on the PATH. So I tried
    running aclocal from within an ash command session (I'm not sure of
    the correct phrase for this. Should I be running everything this
    way?):
    ash
    # aclocal -I.

    This resulted in:
    aclocal: e:/Perl/bin/perl.exe: No such file or directory

    Looking in the aclocal file I find a couple of hard-coded references
    to "e:/Perl". This led me to run grep recursively on everything the
    the /extras amd /usr directories which turned up numerous (100+)
    instances of "e:/" or "E:/". Who know how many references to drives
    other than u: there are?!

    Do I need to be concerned with hard-coded paths within binary files?

    Is there a way to run some program/script to automatically update the
    paths, at least within the text files, to correspond to the current
    environment?

    If I have to edit these manually, do I need to ensure that only
    Unix-style end-of-line's are used? EPM will do this but is there a
    different, commonly used editor for this?

    Should I make sure ALL my edits (e.g source files, header files, etc.)
    use the Unix-style end-of-line's?

    Thanks for you continued help!

    --

    John Small


  11. Re: Smedley's build environment questions

    On 09/25/08 10:44 pm, John Small wrote:
    > On Thu, 25 Sep 2008 23:46:32 UTC, Dave Yeo
    > wrote:
    >
    >> On 09/25/08 09:47 am, John Small wrote:

    [...]
    >>> I had not previously installed libtool. So does this mean the "M4
    >>> macros" are not right in Paul's build environment??

    >> Actually you might just need to run aclocal in the same directory as
    >> configure, probably
    >> ash aclocal -I. (note that is a dot after the I, means include current
    >> directory)

    >
    > The command as you gave it resulted in:
    > aclocal: Can't open aclocal
    >
    > I found an aclocal file in /usr/bin which is on the PATH. So I tried
    > running aclocal from within an ash command session (I'm not sure of
    > the correct phrase for this. Should I be running everything this
    > way?):
    > ash
    > # aclocal -I.


    Running ash aclocal should work, strange that it doesn't. Running in ash
    like above is another solution.

    >
    > This resulted in:
    > aclocal: e:/Perl/bin/perl.exe: No such file or directory
    >
    > Looking in the aclocal file I find a couple of hard-coded references
    > to "e:/Perl". This led me to run grep recursively on everything the
    > the /extras amd /usr directories which turned up numerous (100+)
    > instances of "e:/" or "E:/". Who know how many references to drives
    > other than u: there are?!
    >
    > Do I need to be concerned with hard-coded paths within binary files?


    Generally you shouldn't need to be concerned but there may well be
    exceptions. IIRC Paul uses a package for redirecting names as well
    (can't remember the name right now) which would make hardcoded names not
    matter.
    >
    > Is there a way to run some program/script to automatically update the
    > paths, at least within the text files, to correspond to the current
    > environment?


    A Unix guru would quickly throw a script together using find, xargs and
    sed to do that. I'm not a guru

    >
    > If I have to edit these manually, do I need to ensure that only
    > Unix-style end-of-line's are used? EPM will do this but is there a
    > different, commonly used editor for this?


    Most all ports don't care about line endings luckily. I use EPM or FC/2

    >
    > Should I make sure ALL my edits (e.g source files, header files, etc.)
    > use the Unix-style end-of-line's?


    See above

    >
    > Thanks for you continued help!
    >


    Dave

+ Reply to Thread