Author Topic: GCC - proper include files and libraries, what's the method?  (Read 764 times)

Dariusz Piatkowski

  • Sr. Member
  • ****
  • Thank You
  • -Given: 13
  • -Receive: 8
  • Posts: 403
    • View Profile
GCC - proper include files and libraries, what's the method?
« on: February 23, 2018, 03:24:12 am »
Alright..another installment on my "continuing mission to boldly go where with OS/2 coding where I have not gone before"...LOL, this time all about the CORRECT include files!!!

So I have the following on my machine (things that are specific to GCC):

1) RPM packages for:
- gcc.pentium4                                4.9.2.1-3.oc00           installed
- libgcc-fwd.pentium4                         4.9.2.1-3.oc00           installed
- libgcc1.pentium4                            4.9.2.1-3.oc00           installed
- pthread.i686                           20151229-21.oc00              installed
- pthread-devel.i686                     20151229-21.oc00              installed
- pthread-legacy.i686                    20151229-21.oc00              installed

2) OS/2 Warp Toolkit

3) IBMCPP 3.6.5

All of the above have their own include files. So given that I'm trying to learn how GCC itself is structured and what it actually uses on the local machine, I rule out #2 & #3 (gcc session has no visibility to these) I am struggling to understand why the very same include file (there are multiples) occur in several places, take stdio.h as an example.

Just in the RPM based \usr\ tree I find the following:

Code: [Select]
[G:\usr]dir stdio.h /s

Directory of G:\usr\include
10-26-14   2:17p     19624         124  stdio.h
        1 file(s)      19624 bytes used

Directory of G:\usr\include\c++\4.9.2\tr1
 2-01-15   2:07p      1209         124  stdio.h
        1 file(s)       1209 bytes used

Directory of G:\usr\lib\gcc\i386-pc-os2-emx\4.9.2\include\ssp
 2-01-15   2:08p      3473         124  stdio.h
        1 file(s)       3473 bytes used

Directory of G:\usr\lib\gcc\i386-pc-os2-emx\4.9.2\include-fixed
 2-01-15  12:34p     20124         124  stdio.h
        1 file(s)      20124 bytes used
Total files listed:
        4 file(s)         44430 bytes used
                   4100499 K bytes free

...what the heck? So why these multiple occurencies?

Also, I note that as RPM installed the pthread.i686 package (to support the -pthread gcc option) it put the pthread.h into \usr\include.

So that is Q1, the second issue might be related to this, not sure, and is as follows: attempting to compile thread enabled CPU benchmark causes my GCC session to fail with the following:

Code: [Select]
COLLECT_GCC=gcc
Target: i386-pc-os2-emx
Configured with: ../configure --prefix=/@unixroot/usr --with-sysroot=/@unixroot --enable-shared --enable-languages=c,c++ --enable-frame-pointer --with-gnu-as --disable-bootstrap --disable-multilib --disable-libstdcxx-pch --enable-threads
Thread model: os2
gcc version 4.9.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-o' 'CPUbench.exe' '-mtune=i386' '-march=i386'
 G:/usr/bin/../libexec/gcc/i386-pc-os2-emx/4.9.2/cc1 -quiet -v -iprefix G:/usr/bin/../lib/gcc/i386-pc-os2-emx/4.9.2/ cpubenchmark.c -quiet -dumpbase cpubenchmark.c -mtune=i386 -march=i386 -auxbase cpubenchmark -version -o G:\var\tmp/ccGyMGfL.s
GNU C (GCC) version 4.9.2 (i386-pc-os2-emx)
        compiled by GNU C version 4.7.3, GMP version 5.0.2, MPFR version 3.1.0,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "G:/usr/bin/../lib/gcc/i386-pc-os2-emx/4.9.2/../../../../i386-pc-os2-emx/include"
ignoring nonexistent directory "/@unixroot/usr/local/include"
ignoring nonexistent directory "G:/usr/lib/gcc/../../lib/gcc/i386-pc-os2-emx/4.9.2/../../../../i386-pc-os2-emx/include"
#include "..." search starts here:
#include <...> search starts here:
 G:/usr/bin/../lib/gcc/i386-pc-os2-emx/4.9.2/include
 G:/usr/bin/../lib/gcc/i386-pc-os2-emx/4.9.2/include-fixed
 G:/usr/lib/gcc/../../lib/gcc/i386-pc-os2-emx/4.9.2/include
 G:/usr/lib/gcc/../../lib/gcc/i386-pc-os2-emx/4.9.2/include-fixed
 /@unixroot/usr/include
End of search list.
GNU C (GCC) version 4.9.2 (i386-pc-os2-emx)
        compiled by GNU C version 4.7.3, GMP version 5.0.2, MPFR version 3.1.0,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 40cb22df062740f747e010b72b1ced6d
COLLECT_GCC_OPTIONS='-v' '-o' 'CPUbench.exe' '-mtune=i386' '-march=i386' as -v --traditional-format -o G:\var\tmp/ccWtYHda.o G:\var\tmp/ccGyMGfL.s
GNU assembler version 2.27 (i386-pc-os2-emx) using BFD version (GNU Binutils) 2.
27
COMPILER_PATH=G:/usr/bin/../libexec/gcc/i386-pc-os2-emx/4.9.2/;G:/usr/bin/../libexec/gcc/;G:/usr/bin/../lib/gcc/i386-pc-os2-emx/4.9.2/../../../../i386-pc-os2-emx/bin/
LIBRARY_PATH=G:/usr/bin/../lib/gcc/i386-pc-os2-emx/4.9.2/;G:/usr/bin/../lib/gcc/;G:/usr/bin/../lib/gcc/i386-pc-os2-emx/4.9.2/../../../;/@unixroot/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'CPUbench.exe' '-mtune=i386' '-march=i386'
 ld.exe -o CPUbench.exe G:/usr/bin/../lib/gcc/i386-pc-os2-emx/4.9.2/../../../crt0.o -LG:/usr/bin/../lib/gcc/i386-pc-os2-emx/4.9.2 -LG:/usr/bin/../lib/gcc -LG:/usr/bin/../lib/gcc/i386-pc-os2-emx/4.9.2/../../.. -L/@unixroot/usr/lib G:\var\tmp/ccWtYHda.o -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los
2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2
G:\var\tmp/ccWtYHda.o: Undefined symbol _pthread_create referenced from text segment
G:\var\tmp/ccWtYHda.o: Undefined symbol _pthread_join referenced from text segment
G:\var\tmp/ccWtYHda.o: Undefined symbol _pthread_create referenced from text segment
G:\var\tmp/ccWtYHda.o: Undefined symbol _pthread_join referenced from text segment

...but since 'gcc -c' alone (so compile only) works that means it's the linker that's failing and most likely because the pthread libarary is missing?

That should not be the case since:

Code: [Select]
Directory of G:\usr\lib

12-29-15   9:06a     12424         124  pthread.a
12-29-15   9:06a      4052         124  pthread.dll
12-29-15   9:06a    299570         124  pthread_g.a
12-29-15   9:06a    301982         124  pthread_s.a
        4 file(s)     618028 bytes used

...clearly shows pthread.a and inspecting it I find the _pthread_create/join functions there:

Code: [Select]
IMPORT#37#58c81:
00000000 e _pthread_create
00000000 E _pthread_create=pthr01._pthread_create
...
IMPORT#33#458c8:
00000000 e _pthread_join
00000000 E _pthread_join=pthr01._pthread_join

So what am I missing?

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 100
  • Posts: 1383
    • View Profile
Re: GCC - proper include files and libraries, what's the method?
« Reply #1 on: February 23, 2018, 06:31:54 am »
Hi Dariusz,
First, not only do you have GCC, you also have the CPLUS compiler g++. g++ uses different includes (sometimes). You could try playing around with your hello program by compiling it with g++ instead of gcc. I have little experience with doing it.
GCC (at least traditionally and the rpm installed one) defaults to looking for its include files in /usr/include or here, @UNIXROOT/usr/include as well as the compiler specific ones in \usr\lib\gcc\i386-pc-os2-emx\4.9.2\ (I'll imply the @UNIXROOT)
These can be extended with the -I option or the %C_INCLUDE_PATH% (%CPLUS_INCLUDE_PATH% for cplus) environment variable and to include some you'd use more of the path, eg sys/time.h. Usually system includes are bracketed like <stdio.h> and program specific like "foo.h" in a source code.
Often includes in /usr/include just call one in a subdirectory as well.

Libraries by default are searched for in @UNIXROOT/usr/lib. You can extend the search by using the full path, the -L compiler option (-Lx:/foo/lib) or the %LIBRARY_PATH% environment variable.
Libraries themselves are added to the command line with the -l (small L) parameter, so for pthreads, -lpthread is what you need to add to your compiler command line.
GCC will look for, (default, other flags can change the search order)
1. libfoo_dll.a
2. foo_dll.a
3. libfoo.a
4. foo.a
5. libfoo_s.a
6. foo_s.a
With .lib suffix instead of .a if using -Zomf. Dropping the lib prefix is an OS/2 thing for better 8.3 name compatibility and is usually dropped in the lib line on all platforms, so is usually -lfoo but could be -lx:/path/to/libfoo.a
The _dll.a is a shared import library and _s.a is a static library and without either _s or _dll, could be either. You can use emxomf.exe to convert a .a to .lib library (happens automatically with -Zomf LDFLAG).
The -l and -L are LDFLAGS along with any other that are meant to be passed to the linker.

Types of libraries,
libfoo_dll.a is an import library, pointing at a dll and listing the imports. You can create one with emximp.exe, run it without any parameters for help.
libfoo_s.a is a static library, basically a bunch of object files concated together with an index. They're created with ar.exe or for OMF, emxomfar.exe and the needed functions are linked directly into the program.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 100
  • Posts: 1383
    • View Profile
Re: GCC - proper include files and libraries, what's the method?
« Reply #2 on: February 23, 2018, 06:51:36 am »
You should also look at the EMX documentation, http://hobbes.nmsu.edu/download/pub/os2/dev/emx/v0.9d/emxview.zip.
Things have been simplified, eg EMX needed the -Zomf flags for both CFLAGS and LDFLAGS, now we just need it for LDFLAGS and we can no longer build DOS programs so only have the threaded library so no need for -Zmt etc now but most all are silently eaten for compatibility.
There are also a bunch of EMX functions such as wildcard() to add wildcard support to a program (also the new -Zargs-wild, see also /usr/share/doc/libc-0.6.6/ChangeLog.LIBC and ReleaseNotes.os2)

Dariusz Piatkowski

  • Sr. Member
  • ****
  • Thank You
  • -Given: 13
  • -Receive: 8
  • Posts: 403
    • View Profile
Re: GCC - proper include files and libraries, what's the method?
« Reply #3 on: February 25, 2018, 08:07:33 pm »
Thanks for the wealth of info Dave.

Alright, I've started going through the EMX stuff, find it a bit confusing though why we are still looking at EMX stuff given how old that specific port is in light of the fact that I thought we were moving towards gcc and the migration of the Linux GNU type stuff to our platform, and therefore the replication of how things are done there. So should it not all come down to : one or the other?

OK...more reading, maybe somewhere in there lies the answer.

Now, regarding the '-pthread' and -lpthread' options. So I was using the '-pthread' as the GCC option because by design once the compiler sees the thread support enabled it is supposed to pass that parameter to the linker, and as such, it effectively creates the '-lpthread' parameter. Maybe the problem is that in my output of the gcc run I do not actually find the '-lpthread' showing...???

Anways, OK, thank you again...off I go to do some more reading...lol

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 100
  • Posts: 1383
    • View Profile
Re: GCC - proper include files and libraries, what's the method?
« Reply #4 on: February 25, 2018, 09:09:41 pm »
Thanks for the wealth of info Dave.

Alright, I've started going through the EMX stuff, find it a bit confusing though why we are still looking at EMX stuff given how old that specific port is in light of the fact that I thought we were moving towards gcc and the migration of the Linux GNU type stuff to our platform, and therefore the replication of how things are done there. So should it not all come down to : one or the other?

EMX included GCC. I believe the oldest version I found was something like v2.23 and the newest official was v2.81. EMX also came with various ports of Linux GNU stuff and/or BSD based utilities as well as lots of other peoples ports of similar. EMX could target OS/2, DOS and even Win9x using the RSX dlls (and rebuilt for NT)
After EM moved on, AZ released builds of PGCC (GCC fork that eventually was absorbed back into the GCC trunk) 2.9x, 3.1 and 3.21 builds of GCC with various fixes.
When Mozilla got to a point (between 1.4 and 1.5) where it would no longer build with VACPP, it had to be built with GCC, namely 3.21 and EMX and back then we were a tier 1 platform so Mozilla 1.5 couldn't be released until it worked on OS/2. Unluckily EMX wasn't quite up to the job, Mozilla would just vanish and debugging was hard.
IBM hired AZ to port a newer GCC (3.22 or 3.31, I forget) and then hired Innotek to replace the libc part of EMX with a newer non-GPL version as EM wasn't willing to relicense EMX and IBM didn't want to depend on a GPL libc. This became the Innotek Libc and after Innotek stopped working on it, Knut, who had done a lot of the work for Innotek, continued supporting it as kLIBC. Now mostly BWW is supporting it.
So basically EMX has evolved into our current libc, we still use most of the EMX utilities, though updated and compatibility is mostly maintained. Generally you can take an old EMX app and just recompile for kLIBC.
Some of our toolchain is ancient as well. LD is licensed under GPLv1 with RMS as principal authour for example. As LD is so old and kind of mickeymoused to work with OS/2, it is generally recommended to use -Zomf which leads to using the system linker instead of LD. The difference is really noticeable if you build a DLL. Debugging now also depends on using -Zomf as all the working debuggers are native IBM released. You can build a debug version of hello with the -g -Zomf flags and use the debugger that comes with IBMCPP 3.6.5 (at least I assume it included a debugger).
So basically our current toolchain has evolved from EMX and that is why the documentation is relevant.

Quote
OK...more reading, maybe somewhere in there lies the answer.

Now, regarding the '-pthread' and -lpthread' options. So I was using the '-pthread' as the GCC option because by design once the compiler sees the thread support enabled it is supposed to pass that parameter to the linker, and as such, it effectively creates the '-lpthread' parameter. Maybe the problem is that in my output of the gcc run I do not actually find the '-lpthread' showing...???

It's not that simple with pthreads. Some versions of GCC on various platforms work with the -pthread or -pthreads parameter, usually those systems where pthreads is the native threading implementation. Other versions\ports need the linking to be specified with -lpthread or -lpthreads (might be others as well)
You're probably looking at Linux parameters. Sometimes Mingw ones are better to look at and sometimes OS/2 just does things its own way. Remember our GCC was originally forked back before OS/2 ver 2 was released and while it has been rebased at various times, those patches that Paul is maintaining have old roots.

Quote
Anways, OK, thank you again...off I go to do some more reading...lol
« Last Edit: February 25, 2018, 09:12:04 pm by Dave Yeo »

Dariusz Piatkowski

  • Sr. Member
  • ****
  • Thank You
  • -Given: 13
  • -Receive: 8
  • Posts: 403
    • View Profile
Re: GCC - proper include files and libraries, what's the method?
« Reply #5 on: April 09, 2018, 06:01:30 pm »
Hey Dave!

...Libraries by default are searched for in @UNIXROOT/usr/lib. You can extend the search by using the full path, the -L compiler option (-Lx:/foo/lib) or the %LIBRARY_PATH% environment variable.
Libraries themselves are added to the command line with the -l (small L) parameter, so for pthreads, -lpthread is what you need to add to your compiler command line.
GCC will look for, (default, other flags can change the search order)
1. libfoo_dll.a
2. foo_dll.a
3. libfoo.a
4. foo.a
5. libfoo_s.a
6. foo_s.a
With .lib suffix instead of .a if using -Zomf. Dropping the lib prefix is an OS/2 thing for better 8.3 name compatibility and is usually dropped in the lib line on all platforms, so is usually -lfoo but could be -lx:/path/to/libfoo.a
The _dll.a is a shared import library and _s.a is a static library and without either _s or _dll, could be either. You can use emxomf.exe to convert a .a to .lib library (happens automatically with -Zomf LDFLAG).
The -l and -L are LDFLAGS along with any other that are meant to be passed to the linker...

Alright...so I left the above part of your post as a lead-in to my next topic, in the meantime however let me start off with something much more basic: how the heck do I get the "officially supported" watcom linker system to work?

So here in short is what I have done so far:

1) installed GCC 4.9.2, that seemed to work OK, I was able to compile code and created an EXE out of it, but that was for really simple stuff, basically your typical "hello world"

2) given that I wanted to do the multi-threading benchmarking stuff next I proceeded to deploy the pthread library but that is where I ran into issues at link time, the library functions were not being recognized

OK, so here you provided some great suggestions, I went back to the docs, read it all, multiple times, including on-line research to the EMX/GCC/Watcom specific stuff.

3) I further deployed the various RPM packages which, by the sounds of it, are deemed to be required to successfully build most of the Unix type stuff on our platform, such as the gcc-wrc, gcc-wlink, watcom-wlink-hll, watcom-wrc2. This now gave me the required wl.exe & wrc.exe in \usr\bin and added the following ot my CONFIG.SYS (which I was already experimenting with to learn about these, so I understand why they are being placed there, no problem there):

SET EMXOMFLD_LINKER=wl.exe
SET EMXOMFLD_TYPE=WLINK
SET EMXOMFLD_RC=wrc.exe
SET EMXOMFLD_RC_TYPE=WRC

I am fine with the Watcom approach here, even though the EMXOMFLD stuff could be configured to use IBMCPP 3.0.8 or 3.6.5, or even the default OS/2 Toolkit stuff. I figured the RPM packages support the Watcom way, so I shall proceed down that path first.

Alright...so what's wrong now?

Well, the simplest compile now fails with the following out of the watcom linker:

Code: [Select]
** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 2.0beta1 Limited Availability
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Warning! W1115: file wlink.lnk: line(16): environment name watcom not found
Error! E2093: file wlink.lnk: line(16): cannot open \binw\wlsystem.lnk

...and I'm thinking: OK, what was the point of doing the RPM package installs, getting the experimental versions of wl & wrc on my system if it still appears like I actually need to configure the normal Watcom stuff in the first place?

Heck, I already have Watcom 1.9 installed on my machine, the complete environment, why wouldn't it simply make more sense to use that instead of GCC??? Or IBMCPP 3.6.5 for that case? OK, maybe the answer lies in the IBM stuff being old and un-supported, but the whole process of just trying to get a working GCC environment seems so convoluted that it easily discourages one to pursue it further, and heck, I'm a guy that used to write big-data DBMS stuff (PL/SQL, some Unix scripting, etc) for living at some point in time...LOL, sorry, venting, yeah I know...but my God...!!! :'(

So help me out please, what am I missing?

I will go further down the path of configuring the Watcom linker stuff, but based on the reading I have done so far that will cause the linker to pull the Watcom libraries (because the wlink.lnk & wlsystem.lnk files are configured as such) instead of the preferred GCC libraries, such as the pthread stuff that's sitting in \usr\lib, and that just doesn't make sense to me.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 100
  • Posts: 1383
    • View Profile
Re: GCC - proper include files and libraries, what's the method?
« Reply #6 on: April 10, 2018, 01:10:19 am »
Those are weird errors which I've never gotten while using GCC+wl.exe. and looks like you're using OW rather then GCC. I didn't even have OW installed on ArcaOS until the other day and linking has been working fine here.
For now I'd suggest just using ilink 5.0 by setting your environmental variables to empty, which IIRC has better support for using slashes as the directory separator then the earlier ilinks.
I don't usually use wrc and the main reason I use wl.exe is that ilink fails to link xul.dll due to running out of memory. A debug version of xul.dll uses all the address space and also fails without virtualaddresslimit=3072.

Dariusz Piatkowski

  • Sr. Member
  • ****
  • Thank You
  • -Given: 13
  • -Receive: 8
  • Posts: 403
    • View Profile
Re: GCC - proper include files and libraries, what's the method?
« Reply #7 on: April 10, 2018, 03:22:55 pm »
Those are weird errors which I've never gotten while using GCC+wl.exe. and looks like you're using OW rather then GCC. I didn't even have OW installed on ArcaOS until the other day and linking has been working fine here...

Well, I did eventually find the problem. My installation of OpenWatcom, with all of it's entries in the CONFIG.SYS is what was causing the issue. Funny, sort of similar to what I had ran into installing YUM/RPM and the fact that I had Python 3.x on my machine already. Anyways, taking all the watcom stuff out now allows the RPM versions to execute successfully.

...For now I'd suggest just using ilink 5.0 by setting your environmental variables to empty, which IIRC has better support for using slashes as the directory separator then the earlier ilinks...

Hmm...I have a ZIP version of the ilink 5.0 package, but I did not actually deploy it, is it necessary to do so? The currently installed IBMCPP version is 3.0:

Code: [Select]
[G:\CODE\TOOLS\IBMCPP]ilink

IBM(R) Linker for OS/2(R), Version 03.06.PPK1010917.011116ilink
Copyright (C) IBM Corporation 1988, 1998.
Copyright (C) Microsoft Corp. 1988, 1989.
All rights reserved.

ILink : fatal error LNK1020: no object modules specified

Andreas Schnellbacher

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 15
  • Posts: 291
    • View Profile
Re: GCC - proper include files and libraries, what's the method?
« Reply #8 on: April 10, 2018, 08:05:30 pm »
BTW: I've just found ilink.exe 5.0 in an ancient version (haven't checked others) of Paul's build environment: buildenv20070105, in subdir moztools.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 100
  • Posts: 1383
    • View Profile
Re: GCC - proper include files and libraries, what's the method?
« Reply #9 on: April 11, 2018, 02:24:57 am »
Ilink 5 is still availaible from IBM at ftp://ftp.software.ibm.com/ps/products/warpzilla/ilink50.zip, from the included documentation,
Quote
This document describes the standalone version of the IBM ILINK 5.0 utility
for the OS/2 operating system.  This release of ILINK is separate and
distinct from earlier versions that were packaged with the IBM VisualAge&reg; C++
family of products.  Because these compilers are no longer generally available
and because the standard OS/2 system linker (LINK386) is not designed to handle
the requirements of modern C++ compilers, this release of ILINK is being
provided to address the ongoing needs of the various compilers and assemblers
that are still in use on OS/2.

I forget the specifics, but this was required to build Mozilla after the build system moved to GCC. Now it dies due to running out of memory and wl.exe is required.
Generally wl.exe is probably a better choice for a linker, if only due to source being available though ilink has some advantages such as compressing executables.

@Dariusz, what I generally do is have various setenv.cmd files for different environments where the cmd file will setup the PATH, BEGINLIBPATH, includes etc rather then having them in config.sys.
Talking about OpenWatcom, you should also look at the OpenWatcom Posix like Driver documented in the OpenWatcom Tools user Guide, owcc.exe. This is a mostly GCC (no OS/2 specific options from our GCC) compatible front end for OW.

Dariusz Piatkowski

  • Sr. Member
  • ****
  • Thank You
  • -Given: 13
  • -Receive: 8
  • Posts: 403
    • View Profile
Re: GCC - proper include files and libraries, what's the method?
« Reply #10 on: April 11, 2018, 03:37:27 pm »
Hi Andreas,

BTW: I've just found ilink.exe 5.0 in an ancient version (haven't checked others) of Paul's build environment: buildenv20070105, in subdir moztools.

Turns out the ZIP file I have is the same one which Dave pointed to in his last posting. So I'm all good here, going through the readme of the ilink version in that ZIP, which is the latest 5.0.

Thank you!

Dariusz Piatkowski

  • Sr. Member
  • ****
  • Thank You
  • -Given: 13
  • -Receive: 8
  • Posts: 403
    • View Profile
Re: GCC - proper include files and libraries, what's the method?
« Reply #11 on: April 11, 2018, 04:00:46 pm »
Hi Dave,

Ilink 5 is still availaible from IBM at ftp://ftp.software.ibm.com/ps/products/warpzilla/ilink50.zip, from the included documentation...

Yup, same one I already have in my ZIP file, so I'm all good here now as far as having the latest working IBM package and will deploy that on my machine.

...@Dariusz, what I generally do is have various setenv.cmd files for different environments where the cmd file will setup the PATH, BEGINLIBPATH, includes etc rather then having them in config.sys...

As it happens that is precisely the approach I have taken to organizing all of this on my machine. I've been using Visual SlickEdit for a number of years now, having originally purchased the official OS/2 v4.0 and using multiple newer version professionally in other environments (Unix - Solaris actually and Win-world). Anyways, I love it b/c it is so flexible, much of the configuration revolving around the concept of Project based configuration.

So on my machine I actually have the following defined:

1) IBM CPP 3.6.5
2) GCC 4.9.2
3) Borland
4) Watcom
5) Java

...and for each of these projects different Compile/Build/Re-Bulid/Debug/Execute option are defined.

In my case I have been primarily using the IBM CPP setups in the past, all of my attempts being really small-scale projects, more of really understanding the OS/2 API platform. If you recall, some years ago I had actually asked you for help in understanding the FFMPEG stuff as my goal was to eventually build the latest version of this and start maintaining it regularly.

Anyways, so where I am today is in working through the details of the EMX/GCC stuff so that I can finalize the project configuration options and be able to successfully build a EXE using that environment. Of course as the proejcts get bigger they get more complex and simply using a gcc compile line may not be sufficient. That is fine, the VSlick Build option allows me to configure the proper use of 'make', etc.

...Talking about OpenWatcom, you should also look at the OpenWatcom Posix like Driver documented in the OpenWatcom Tools user Guide, owcc.exe. This is a mostly GCC (no OS/2 specific options from our GCC) compatible front end for OW...

I probably need to update my OpenWatcom install first, the Tools User Guide only finds a single occurence of 'POSIX' right now and I did not find anything else in there matching your description. It looks to me like I'm currently using rel 1.4, I believe the last official release is 1.9 (I have that here already) and just the other day I went out there looking for the current status of the project and found 2.0c, so I shall give that update a go first.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 100
  • Posts: 1383
    • View Profile
Re: GCC - proper include files and libraries, what's the method?
« Reply #12 on: April 11, 2018, 04:16:20 pm »
I think the 2c that you refer is on github and is the fork. The latest beta of 2.0 is at netlabs ftp site in incoming.

Dariusz Piatkowski

  • Sr. Member
  • ****
  • Thank You
  • -Given: 13
  • -Receive: 8
  • Posts: 403
    • View Profile
Re: GCC - how to enable multi-threading in CPP?
« Reply #13 on: April 18, 2018, 06:31:41 am »
OK, so attempting to build a super-simple multi-threaded app:

Code: [Select]
#include <iostream>
#include <thread>

using namespace std;

void hello_world()
{
  cout << "Hello from thread!\n";
}

int main()
{
  thread t(hello_world);
  t.join();
  return 0;
}

Compiling with the following GCC options:
'-march=amdfam10 -O2 -pipe -v -idirafter g:/code/tools/toolkit/h -Zomf -std=c++11'

...produces the following compile time error:

Code: [Select]
G:\code\source\GCC\threads2.cpp:13:3: error: 'thread' was not declared in this scope
   thread t(hello_world);
   ^
G:\code\source\GCC\threads2.cpp:14:3: error: 't' was not declared in this scope
   t.join();

So what's the secret? I see a lot of similar problems on the Winx version of their GCC port (MinGW), mostly stating that the thread library does not implement the native threads...is that a problem for us on OS/2 as well?

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 100
  • Posts: 1383
    • View Profile
Re: GCC - proper include files and libraries, what's the method?
« Reply #14 on: April 18, 2018, 07:25:02 am »
Quote
So what's the secret? I see a lot of similar problems on the Winx version of their GCC port (MinGW), mostly stating that the thread library does not implement the native threads...is that a problem for us on OS/2 as well?

Probably. If you look in the pthreads dev package, there is only pthread.h (and libraries)
Best to use native threads anyways, searching duckduckgo with "example code _beginthread site:edm2.com"
gives some examples such as this one, (I saved it as thread.cpp)

Code: [Select]
// file: hello_thread.c++
#include <iostream>
#include <process.h>

#define INCL_DOSPROCESS
#include <os2.h>

void hello( void * )
{
  std::cout << "Hello from thread." << std::endl;
}

int main( int argc, char *argv[] )
{
  _beginthread( hello, 0, 4096 * 10, 0 );
  DosSleep( 10 );                       // Allow the thread to finish.
}

which compiles fine with
Code: [Select]
g++ -Zomf thread.cppand
Code: [Select]
H:\tmp>thread
Hello from thread.
Seems best to start with minimum flags to g++. More can be added later.
Note lots of the GCC examples are for EMX and will have -Zmt meaning to use the multi-threading library, this is unneeded now (doesn't hurt though) as we only have the multi-threading library, the single threaded library was used for DOS.