Updated GCC builds

[Paul Smedley]

Hi All,

Updated GCC 4.5.4 that fixes some dllexport bugs is at
http://os2ports.smedley.id.au

An experimental build of GCC 4.6.4 is at
http://smedley.id.au/tmp/gcc-4.6.4-os2-20130810.zip

Feedback appreciated.

Cheers,

Paul

[Paul Smedley]

Hi All,

On 10/08/13 19:27, Paul Smedley wrote:
> An experimental build of GCC 4.6.4 is at
> http://smedley.id.au/tmp/gcc-4.6.4-os2-20130810.zip

linking with a shared libgcc is broken with this build - either link
with -static-libgcc or wait for a refreshed build.

Cheers,

Paul

[Paul Smedley]

http://smedley.id.au/tmp/gcc-4.6.4-os2-20130811.zip is now available

Cheers,

Paul

[KO Myung-Hun]

Hi/2.

Thanks for your efforts. ^^

BTW, I encountered the following problem when compiling VLC.

-----
make.exe[5]: Entering directory `F:/lang/work/vlc/vlc.git/modules/access'
/bin/sh ../../libtool --tag=CC --mode=compile gcc -std=gnu99
-DHAVE_CONFIG_H -I. -I../.. -DMODULE_NAME_IS_$(p="unzip.lo";
p="${p##*/}"; p="${p#lib}"; echo "${p%_plugin*}")
-DMODULE_STRING=\"$(p="unzip.lo"; p="${p##*/}"; p="${p#lib}"; echo
"${p%_plugin*}")\" -D__PLUGIN__ -I../../include -I../../include
-march=i486 -Wall -Wextra -Wsign-compare -Wundef -Wpointer-arith
-Wbad-function-cast -Wwrite-strings -Wmissing-prototypes
-Wvolatile-register-var -Werror-implicit-function-declaration -pipe
-ffast-math -funroll-loops -MT unzip.lo -MD -MP -MF .deps/unzip.Tpo -c
-o unzip.lo `test -f 'zip/unzip/unzip.c' || echo './'`zip/unzip/unzip.c
libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..
-DMODULE_NAME_IS_unzip.lo -DMODULE_STRING=\"unzip.lo\" -D__PLUGIN__
-I../../include -I../../include -march=i486 -Wall -Wextra -Wsign-compare
-Wundef -Wpointer-arith -Wbad-function-cast -Wwrite-strings
-Wmissing-prototypes -Wvolatile-register-var
-Werror-implicit-function-declaration -pipe -ffast-math -funroll-loops
-MT unzip.lo -MD -MP -MF .deps/unzip.Tpo -c zip/unzip/unzip.c
-DDLL_EXPORT -DPIC -o .libs/unzip.o
gcc: error: spawnvp: No such file or directory
make.exe[5]: *** [unzip.lo] Error 1
make.exe[5]: Leaving directory `F:/lang/work/vlc/vlc.git/modules/access'
-----

--
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.24 on Intel Core i7-3615QM 2.30GHz with 8GB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr

[A.D. Fundum]

> VLC.
> -march=i486

FWIW and off-topic: if you can notice any significant speed gain, I'ld
suggest to change that to a 80586, the Pentium-generation. Based on
the CPU speed and bus speed of e.g. a 80486 DX2 50 MHz, I doubt that
anybody will grab a 80486 to watch a video with VLC and expect it to
work. Both an i486 and an i586 don't match the minimum requirements of
your OS (W4: 80386, eCS: > Pentium I), so that's not a reason to stick
to an i486.

With a Warp 4 80486 notebook and the simple 320x200
x:\OS2\APPS\KLONDIKE.FLC video, played by the default OS player, the
CPU load is about 50%. So it's possible to play videos with i486
hardwarde, but this'll be about the limit of that generation of CPUs.
By default I'ld always suggest to print "same as OS" on the box, i.e.
i386 (keeping Warp 4 users in mind) or no optimization, but there are
exceptions like modern web browsing beasts (i486: not enough
installable RAM for real use, for one) or up-to-date video players.


--

[Paul Smedley]

Hi All,

http://smedley.id.au/tmp/gcc-4.6.4-os2-20130812.zip

Fixes a bug relating to wildcard expansion

Cheers,

Paul

[Paul Smedley]

Hi KO,

On 11/08/13 22:41, KO Myung-Hun wrote:
> Hi/2.
>
> Paul Smedley wrote:
>> On 11/08/13 10:32, Paul Smedley wrote:
>>> Hi All,
>>>
>>> On 10/08/13 19:27, Paul Smedley wrote:
>>>> An experimental build of GCC 4.6.4 is at
>>>> http://smedley.id.au/tmp/gcc-4.6.4-os2-20130810.zip
>>>
>>> linking with a shared libgcc is broken with this build - either link
>>> with -static-libgcc or wait for a refreshed build.
>>
>> http://smedley.id.au/tmp/gcc-4.6.4-os2-20130811.zip is now available
>>
>
> Thanks for your efforts. ^^
>
> BTW, I encountered the following problem when compiling VLC.
>
> -----

<snip>

> gcc: error: spawnvp: No such file or directory

I normally see errors like this when the system needs a reboot.....

Cheers,

Paul

[KO Myung-Hun]

Hi/2.

It's a minimum requirement to compile VLC.

And I don't think there are significant performance differences between
i486 and i586.

[Marcel Müller]

On 12.08.13 11.34, Paul Smedley wrote:
> http://smedley.id.au/tmp/gcc-4.6.4-os2-20130812.zip

GCCENV throws an error. And also if I try to set gcc-usr-path as
parameter the resulting directory is always invalid, since it always
ends with \usr which is obviously wrong.

D:\usr\local464\bin>GCCENV.CMD
Error: cannot find gcc.exe in 'D:\usr\local464\usr'!

syntax: gccenv.cmd [gcc-usr-path [linker]]

[gcc-usr-path] is the path to the /usr directory of the gcc distro.
If [gcc-usr-path] isn't specified, the script assumes it's located
81 *-* say 'in /usr/local'_shortver 'of the gcc distro and
deducts the path based on that.
'
61 *-* call Usage;
REX0016E: Error 16 running D:\usr\local464\bin\GCCENV.CMD line 81:
Label not found
REX0229E: Error 16.1: Label "NOVALUEHANDLER" not found

OK, it seems that only the error message is garbage. That confused me,
so I passed the wrong parameters - got it working.


Furthermore I get many funny warnings when compiling inline assembly:

../interlocked.h: Assembler messages:
../interlocked.h:110: Warning: line numbers must be positive; line
number 0 rejected

The code is:
static __inline__ void InterlockedInc(__volatile__ unsigned *pu)
{ __asm__ __volatile__("lock; incl %0"
: "+m" (*pu)
:
: "cc");
}

Other inline assembly (fftw3) creates similar warnings.


When linking a DLL I get an error about a missing dll0.obj:

gcc -Zcrtdll -Zomf -lstdc++ -Ld:\usr\lib\tcpipv4 -s -Zdll -o
.\fft123.dll fft.o kernel\kernel.a dft\codelets\inplace\dft_inplace.a
dft\codelets\standard\dft_standard.a dft\codelets\dft_codelets.a
dft\dft.a rdft\codelets\hc2r\hc2r.a rdft\codelets\r2hc\r2hc.a
rdft\codelets\r2r\r2r.a rdft\codelets\rdft_codelets.a rdft\rdft.a
reodft\reodft.a api\api.a ..\utils\utilfct.a fft_icc.def
weakld: cannot open object file 'D:\Dev\TRUNC\src\fft123\dll0.obj'.
emxomfld: weak prelinker failed. (rc=8)

Are there some files of the runtime library missing?


Marcel

[Dave Yeo]

KO Myung-Hun wrote:
> It's a minimum requirement to compile VLC.
>
> And I don't think there are significant performance differences between
> i486 and i586.

There might be advatages to using P6, namely better alignment
Dave

[A.D. Fundum]

> And I don't think there are significant performance differences
> between i486 and i586.

Think? Could be worth a brief test, since it's not about general
differences and this indeed is the most important condition. No gain,
no reason to change. Any speed gain which can be noticed can be
siginificant. In the case of an individual user it can come down to a
CPU load of 99% instead of 101%, with video speed being a classic
problem in the world of IBM and Lenovo hardware. I don't know if the
difference can be noticed while playing an average video, so your
thought could very well be quite right.


--

[KO Myung-Hun]

Bad news first,

the reboot does not fix this problem.

Good news,

your fixed gcc464 has no this problem. ^^

Again, bad news,

the executable crashes due to SYS3171. T.T

[A.D. Fundum]

>> differences between i486 and i586.

> There might be advatages to using P6, namely better alignment

I wasn't trying to push it, but I also don't think that a P5 (maybe
133 MHz, 160 MB of 60ns EDO RAM, 66 MHz bus speed?) is a typical
choice to play a modern video with VLC. If needed, call it VLC for
eCS, which implies the use of such a CPU anyway. Just undo the minor
change if there's no speed gain, and apply the optimization only to
up-to-date video _players_.

FYI, a 500 MHz Pentium III is hardly capable of playing a downloaded
typical Youtube-video with KMP with a CPU load trying to exceed 100%.
People with e.g. FFmpeg/386 still can try to convert and resize such a
HQ video for their 386 video player, and users of VLC/P6 aren't
wasting their limited number of horses.


--

[gianf...@gmail.com]

I might even agree with you, but consider that there are many old computers still alive and that work well with OS/2, a cpu PIII 500 is definitely effort for you, but from 800 up and only 256 of ram, VLC performs quite well (direct experience), so apart from ram and gpu, maybe works also older, so this switch would mean cutting out a slice of users.

Gianfli

[Paul Smedley]

Hi All,

On 11/08/13 14:03, Paul Smedley wrote:

I've now added a GCC 4.7.3 build at
https://dl.dropboxusercontent.com/u/76425158/gcc-4.7.3-os2-20130818.zip

This one seems to be to be 'better' than the previous 4.6.4 build.
Scribus builds that were failing when build with 4.6.4 are working with
4.7.3.

Feedback appreciated.

Cheers,

Paul

[Dave Yeo]

Paul Smedley wrote:
> I've now added a GCC 4.7.3 build at
> https://dl.dropboxusercontent.com/u/76425158/gcc-4.7.3-os2-20130818.zip
>
> This one seems to be to be 'better' than the previous 4.6.4 build.
> Scribus builds that were failing when build with 4.6.4 are working with
> 4.7.3.
>
> Feedback appreciated.

Curious how you're working around AOUT support having been dropped after
4.4.x?
Be nice if libc07 ever gets out with ELF support
Dave

[Paul Smedley]

Hi Dave,

aout support is still there....

[KO Myung-Hun]

Paul Smedley wrote:
> Hi All,
>
> On 11/08/13 14:03, Paul Smedley wrote:
>> On 11/08/13 10:32, Paul Smedley wrote:
>>> Hi All,
>>>
>>> On 10/08/13 19:27, Paul Smedley wrote:
>>>> An experimental build of GCC 4.6.4 is at
>>>> http://smedley.id.au/tmp/gcc-4.6.4-os2-20130810.zip
>>>
>>> linking with a shared libgcc is broken with this build - either link
>>> with -static-libgcc or wait for a refreshed build.
>>
>> http://smedley.id.au/tmp/gcc-4.6.4-os2-20130811.zip is now available
>
> I've now added a GCC 4.7.3 build at
> https://dl.dropboxusercontent.com/u/76425158/gcc-4.7.3-os2-20130818.zip
>
> This one seems to be to be 'better' than the previous 4.6.4 build.
> Scribus builds that were failing when build with 4.6.4 are working with
> 4.7.3.
>
> Feedback appreciated.
>

Unfortunately, same as 464 in case of VLC.

[Paul Smedley]

Hi All,

On 19/08/13 22:34, KO Myung-Hun wrote:
>
>
> Paul Smedley wrote:
>> Hi All,
>>
>> On 11/08/13 14:03, Paul Smedley wrote:
>>> On 11/08/13 10:32, Paul Smedley wrote:
>>>> Hi All,
>>>>
>>>> On 10/08/13 19:27, Paul Smedley wrote:
>>>>> An experimental build of GCC 4.6.4 is at
>>>>> http://smedley.id.au/tmp/gcc-4.6.4-os2-20130810.zip
>>>>
>>>> linking with a shared libgcc is broken with this build - either link
>>>> with -static-libgcc or wait for a refreshed build.
>>>
>>> http://smedley.id.au/tmp/gcc-4.6.4-os2-20130811.zip is now available
>>
>> I've now added a GCC 4.7.3 build at
>> https://dl.dropboxusercontent.com/u/76425158/gcc-4.7.3-os2-20130818.zip
>>
>> This one seems to be to be 'better' than the previous 4.6.4 build.
>> Scribus builds that were failing when build with 4.6.4 are working with
>> 4.7.3.
>>
>> Feedback appreciated.
>>
>
> Unfortunately, same as 464 in case of VLC.
>

Seems this is a bug related to Optimizations....

I have a simple testcase that gives a sigsegv when compiled using -O1 or
above but works with no optimizations.

Seems something that is enabled by default at -O1 causes crashes on OS/2
since GCC 4.6.x

[Paul Smedley]

New builds at http://os2ports.smedley.id.au

- GCC 4.7.3
- binutils 2.23.2

[KO Myung-Hun]

Hi/2.

Some linker warnings such as 'Unwind something' are gone. Maybe due to
newly added libc_dll.[a/lib] ?

Thanks.

[Mentore Siesto]

Il giorno Sat, 7 Sep 2013 09:28:44 UTC, Paul Smedley
<pa...@smedley.id.au> ha scritto:

> New builds at http://os2ports.smedley.id.au
>
> - GCC 4.7.3
> - binutils 2.23.2

Good news. I'm a bit busy these days, but I surely will install and
try them as soon as I have learned how to install QT development
libraries where I want (and not where YUM/RPM choose per default).

--
Mentore Siesto

[gianf...@gmail.com]

Just installed, compile quite well for most of my ports but all my executables does not works, this is output in first run:

Killed by SIGSEGV
pid=0x434e ppid=0x4348 tid=0x0001 slot=0x00b8 pri=0x0200 mc=0x0001
C:\IMAGEMAGICK\BIN\CONVERT.EXE
cs:eip=005b:000000a6 ss:esp=0053:0024ee20 ebp=000dff0e
ds=0053 es=0053 fs=150b gs=0000 efl=00010206
eax=00000000 ebx=00000184 ecx=434e0002 edx=00776720 edi=00000000 esi=00000000
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

All works fine compiled using your 4.4.6.
Still not be able to get a shared lib.
Build env rexx script is always the same, i only changed gcc paths and all is in on U:\ drive.
Any suggests?

[Paul Smedley]

Hi KO,

On 07/09/13 22:41, KO Myung-Hun wrote:
> Hi/2.
>
> Paul Smedley wrote:
>> New builds at http://os2ports.smedley.id.au
>>
>> - GCC 4.7.3
>> - binutils 2.23.2
>
> Some linker warnings such as 'Unwind something' are gone. Maybe due to
> newly added libc_dll.[a/lib] ?

Yeah probably. The updated libc_dll.[a/lib] ensures the libgcc functions
from GCC 4.7.3 are used, not the older ones bundled in libc06x.dll from
gcc 3.3.5

It was an omission from the earlier GCC 4.7.3 builds.

btw the source is now present at github

Cheers,

Paul

[Paul Smedley]

Not really...what version of imagemagick are you building, I can do a
test build here.

Cheers,

Paul

[gianf...@gmail.com]

> Not really...what version of imagemagick are you building, I can do a
>
> test build here.

Imagemagick ver. is 6.8.6-9, latest.

Courious that works if compiled using your gcc 4.4.6, just rebuild, not yet tested previous gcc ver.
All works fine using 4.4.6, not linked against libtiff (both gcc ver. due to undefined TIFFReadRGBATile during configuring, prob an lzma or zlib specific version?, this one http://hobbes.nmsu.edu/download/pub/os2/dev/util/Tiff-4.0.1-os2.zip):

configure:31510: checking tiff.h usability
configure:31510: gcc.exe -std=gnu99 -std=gnu99 -c
configure:31510: checking for tiff.h
configure:31510: result: yes
configure:31518: checking tiffio.h usability
configure:31635: $? = 0
configure:31644: result: yes
.................................
yes...
yes...
yes...
configure:31652: checking for TIFFReadRGBATile in -ltiff
........................................................
Error! E2028: _TIFFReadRGBATile is an undefined reference
file U:\tmp\ccuVpDiN.o(conftest.c): undefined symbol _TIFFReadRGBATile
weakld: error: Unresolved symbol (UNDEF) '_TIFFReadRGBATile'.
weakld: info: The symbol is referenced by:
U:\tmp\ccuVpDiN.o

should i compare both environment script linexline? ,consider that are the same.

Of course there is still something wrong with my build environment and since I was at the old EMX I need to take more familiarity with your environment, but a thorough tuning takes time. Consider that often is more the time I spent in tuning the environment instead of analyzing the code itself :-)
Best regards

[Dave Yeo]

gianf...@gmail.com wrote:
> All works fine using 4.4.6, not linked against libtiff (both gcc ver. due to undefined TIFFReadRGBATile during configuring, prob an lzma or zlib specific version?, this onehttp://hobbes.nmsu.edu/download/pub/os2/dev/util/Tiff-4.0.1-os2.zip):

Be a libtiff error. Watch out for EMX compiled libraries as they are
generally incompatible with klibc.
Dave