i've a problem with os2260full... i bit the bullet and wiped my old os2 2.4.0(?? or 2.4.2???) install... now none of my projects compile... they complain about "Error: Can't call the assembler, error -1 switching to external assembling"...

in downloaded os2260full.zip, transferred it to the os/2 box, unzipped it into a /tmp directory and then ran the install tool... after an hour or so, i came back and it was complete... then i tried to compile one of my projects and ran into the above error...

HELP!!

This should be easy to fix (FAQ item, in fact ;-) ). Nevertheless, in order to determine the reason, please do the following:

1) Compile with the -s parameter, run the created ppas.cmd and check the error message displayed when trying to run GNU AS from this command file.

2) Check your PATH and LIBPATH (especially the latter) settings to contain a reference to the DLL directory in your FPC installation.

Tomas

really? i haven't found a FAQ document that covered this... at least nothing that was "in your face" with this specific problem... but maybe i don't know where to look :/

Nevertheless, in order to determine the reason, please do the following: 1) Compile with the -s parameter, run the created ppas.cmd and check the error message displayed when trying to run GNU AS from this command file.

compile what? my project? how is that done? i'm only running fp to load my source code and then hitting F9 or ALT-F9 to compile... i don't know how to do it any other way :/ [never mind, see below]

2) Check your PATH and LIBPATH (especially the latter) settings to contain a reference to the DLL directory in your FPC installation.

ahhh... now /THIS/ might be the ticket... when the install completed, there was a box on the screen that said to make sure that the PATH and LIBPATH contained the proper text and it specifically said what that text should be... so i dutifully copy'n'pasted it into the editor i had config.sys opened in... saved and closed everything and rebooted...

when i looked at it just now, the LIBPATH is set to h:\fp\2.6.0\bin\dll when it should have been set to h:\fp\2.6.0\dll... i had noted this difference when i made the edit because it should have been a simple modification of the existing 2.4.2 entries...

[time passes]

ok, have fixed the LIBPATH and rebooted... it takes a bit (~5 minutes) for the thing to come back up with all of its services and such ready to go and be at the point of ready for someone to interact with it... OK, so now it gets further... the error now is "Error: Error while linking"...

[time passes]

ok, i figured out how to compile with -s and then i ran the ppas.cmd file... it apparently has completed successfully... i do have a bright shiny new exe file... now to figure out what's wrong with the normal way that fp does it as compared to the way fpc is doing it...

.
.

http://www.freepascal.org/faq.var#os2-as-failing (also available as h:\fp\2.6.0\doc\faq.htm on your machine now ;-) ).

> Nevertheless, in order to determine the reason, please do the following:

.
.

Strange. Looking at the installer sources, I don't understand how it could behave that way. I'll recheck it and let you know the results.

.
.

You may want to check the differences between fp.ini and fpc.cfg. Also, if you have an OS/2 version of the tool 'which' (available e.g. from http://silk.apana.org.au/utils.html or as an internal command within 4OS2 shell if you use that one), you might want to check a possible difference in path returned for 'which as' and 'which ld'.

Tomas

Tomas Hajny wrote

On Fri, January 13, 2012 16:48, waldo kitty wrote: > On 1/13/2012 05:40, Tomas Hajny wrote: >> On Fri, January 13, 2012 11:27, waldo kitty wrote:

.
.

.
.

Unfortunately, there's a bug in the installer indeed resulting in suggesting a wrong directory setting for LIBPATH. :-(

The problem only exists for people not having the respective libraries in LIBPATH from some other activities. I fixed the problem and uploaded a fixed installer to the FPC FTP server (but you obviously don't need to use it any longer since the only error was a wrong text in the message box and you already have the right version set in your CONFIG.SYS file).

Sorry for the troubles and thanks for notifying me about the issue

Tomas

i use 4OS2 and both return the same path...

which as

209 rwx 1 bin 212992 Feb 23 2004 10:43:38 h:\fp\2.6.0\bin\os2\as.exe

which ld

97 rwx 1 bin 98308 Dec 19 1998 18:51:42 h:\fp\2.6.0\bin\os2\ld.exe

i've also and fpc.cfg and don't find anything related that might be causing this... the only thing i have done with those files, actually, is to replace "2.6.0" with "$FPCVERSION" so that i can easily share (ie: copy) the project directory with other machines... i've initially developed this tool on w2k and then copied that directory over to the OS/2 box... i also have a copy on my vista laptop so i can work on it when i'm at work or otherwise out and about with my laptop ;)

waldo kitty wrote

On 1/13/2012 12:24, Tomas Hajny wrote: > On Fri, January 13, 2012 16:48, waldo kitty wrote:

.
.

<off topic>My memory didn't serve well here, this output clearly comes from some external port of the original implementation of the 'which' tool installed on your machine and I just found that 4OS2 doesn't contain such an internal command contrary to my original belief. That doesn't change anything, it serves the intended purpose anyway.</off topic>

Alright, this indeed doesn't suggest anything weird.

Yes, that certainly makes sense. My point was mainly - could it be that you have -FD option specified in fpc.cfg while it is missing in fp.cfg (sorry, not fp.ini) and in effect for the compilation mode selected in the IDE (NORMAL/DEBUG/RELEASE), or that you have this option in both the files but pointing to different directories?

Tomas

not a problem... >which which
53 rwx 1 bin 54031 Apr 21 2000 12:25:36 X:\o2progs\gnu\tools\which.exe

yup, looks like i have (some of?) the gnu tools installed, also... but they are later in the path that this fpc install... fpc is at the head of the path and libpath...

Alright, this indeed doesn't suggest anything weird.

ok...

ahhh... yes, i have taken great pains to ensure that all three default "stanzas" contain identical paths no matter which "selector" is chosen... i've only got one project that needs an additional path and that's because i've kept a portion of synapse local to it...

however, those are only related to finding source files... i do see where i can specify a path for tools in fpc and it is set to the default... with my $FPCVERSION change... none of my fp.cfg files have -FD in them and i don't know that i know where it should appear...

but this options hasn't been in the fp.cfg file ever that i know of... have i found another bug?

waldo kitty wrote

On 1/14/2012 08:06, Tomas Hajny wrote: > On 14 Jan 12, at 5:13, waldo kitty wrote: >> On 1/13/2012 12:24, Tomas Hajny wrote: >>> On Fri, January 13, 2012 16:48, waldo kitty wrote:

.
.

No, that isn't a bug, -FD isn't mandatory. It just allows specifying a concrete installation of as and ld regardless of the PATH setting. That's also why I asked about it - if fp.cfg had a reference to another directory while fpc used just PATH based search, it could be a reason of the different behaviour.

Is there any difference between ppas.cmd created by fp.exe and fpc.exe if you add option -s to compilation from both? Any difference between link.res file created in the two cases? Do you see any error messages from the linker when running it from ppas.cmd created by fp.exe for compilation with -s?

Tomas

Tomas

Tomas Hajny wrote

Is there any difference between ppas.cmd created by fp.exe and fpc.exe if you add option -s to compilation from both?

i can't find a ppas.cmd when i use "fp -s" and hit F9 or ALT-F9 to compile... it still fails with an error linking... i am allowing the dsk file to load the files i had open...

here's the ppas.cmd from "fpc -s" though...

[---- fpc-ppas.cmd ----]
@echo off
SET THEFILE=satsort
echo Assembling %THEFILE%
"h:\fp\2.6.0\bin\os2\as.exe" -o satsort.o satsort.s if errorlevel 1 goto asmend
Del satsort.s
SET THEFILE=satsort.exe
echo Linking %THEFILE%
"h:\fp\2.6.0\bin\os2\ld.exe" -o satsort.out @link.res if errorlevel 1 goto linkend
"h:\fp\2.6.0\bin\os2\emxbind.exe" -b -s -w -k256 -h1 -o satsort.exe satsort.out -ai -s8
if errorlevel 1 goto linkend
del satsort.out
if errorlevel 1 goto linkend
goto end
:asmend
echo An error occured while assembling %THEFILE%
goto end
:linkend
echo An error occured while linking %THEFILE%
:end
[---- end ----]

Any difference between link.res file created in the two cases?

yes...

the first thing i note is the fp link.res includes the .\ directory and the fpc one does not... indicated with a 1 below...

the second thing i note is the fp link.res messes up the directory we're working in for the program.o file being compiled whereas the fpc one doesn't say the directory but only the program.o... indicated with a 2 below...

[---- fp-link.res ----]
1 -L.\
-LH:\FP\2.6.0\UNITS\OS2\RTL\
-LH:\FP\2.6.0\UNITS\OS2\zlib\
-LH:\FP\2.6.0\UNITS\OS2\x11\
-LH:\FP\2.6.0\UNITS\OS2\unzip\
-LH:\FP\2.6.0\UNITS\OS2\tcl\
-LH:\FP\2.6.0\UNITS\OS2\symbolic\
-LH:\FP\2.6.0\UNITS\OS2\rexx\
-LH:\FP\2.6.0\UNITS\OS2\regexpr\
-LH:\FP\2.6.0\UNITS\OS2\paszlib\
-LH:\FP\2.6.0\UNITS\OS2\pasjpeg\
-LH:\FP\2.6.0\UNITS\OS2\os2units\
-LH:\FP\2.6.0\UNITS\OS2\libpng\
-LH:\FP\2.6.0\UNITS\OS2\libgd\
-LH:\FP\2.6.0\UNITS\OS2\lexyacc\
-LH:\FP\2.6.0\UNITS\OS2\imlib\
-LH:\FP\2.6.0\UNITS\OS2\hermes\
-LH:\FP\2.6.0\UNITS\OS2\hash\
-LH:\FP\2.6.0\UNITS\OS2\gtk1\
-LH:\FP\2.6.0\UNITS\OS2\fv\
-LH:\FP\2.6.0\UNITS\OS2\fppkg\
-LH:\FP\2.6.0\UNITS\OS2\fpmkunit\
-LH:\FP\2.6.0\UNITS\OS2\fpgtk\
-LH:\FP\2.6.0\UNITS\OS2\fcl-xml\
-LH:\FP\2.6.0\UNITS\OS2\fcl-res\
-LH:\FP\2.6.0\UNITS\OS2\fcl-registry\
-LH:\FP\2.6.0\UNITS\OS2\fcl-process\
-LH:\FP\2.6.0\UNITS\OS2\fcl-passrc\
-LH:\FP\2.6.0\UNITS\OS2\fcl-net\
-LH:\FP\2.6.0\UNITS\OS2\fcl-json\
-LH:\FP\2.6.0\UNITS\OS2\fcl-js\
-LH:\FP\2.6.0\UNITS\OS2\fcl-image\
-LH:\FP\2.6.0\UNITS\OS2\fcl-fpcunit\
-LH:\FP\2.6.0\UNITS\OS2\fcl-db\
-LH:\FP\2.6.0\UNITS\OS2\fcl-base\
-LH:\FP\2.6.0\UNITS\OS2\chm\
-LH:\FP\2.6.0\UNITS\OS2\bzip2\
-LH:\FP\2.6.0\UNITS\OS2\
-LH:\FP\2.6.0\BIN\OS2\
H:\FP\2.6.0\UNITS\OS2\RTL\prt0.o
2 h:\fpc\projects\satellite\h:\fpc\projects\satellite\satsort.o H:\FP\2.6.0\UNITS\OS2\RTL\system.o
H:\FP\2.6.0\UNITS\OS2\RTL\heaptrc.o
H:\FP\2.6.0\UNITS\OS2\RTL\sysutils.o
H:\FP\2.6.0\UNITS\OS2\RTL\strutils.o
H:\FP\2.6.0\UNITS\OS2\RTL\objects.o
H:\FP\2.6.0\UNITS\OS2\RTL\math.o
H:\FP\2.6.0\UNITS\OS2\RTL\crt.o
H:\FP\2.6.0\UNITS\OS2\RTL\dos.o
H:\FP\2.6.0\UNITS\OS2\RTL\objpas.o
H:\FP\2.6.0\UNITS\OS2\RTL\sysconst.o
H:\FP\2.6.0\UNITS\OS2\RTL\doscalls.o
H:\FP\2.6.0\UNITS\OS2\RTL\strings.o
H:\FP\2.6.0\UNITS\OS2\RTL\system.a
H:\FP\2.6.0\UNITS\OS2\RTL\crt.a
H:\FP\2.6.0\UNITS\OS2\RTL\doscalls.a
[---- fp-link.res ends ----]

[---- fpc-link.res ----]
-LH:\FP\2.6.0\UNITS\OS2\RTL\
-LH:\FP\2.6.0\UNITS\OS2\zlib\
-LH:\FP\2.6.0\UNITS\OS2\x11\
-LH:\FP\2.6.0\UNITS\OS2\unzip\
-LH:\FP\2.6.0\UNITS\OS2\tcl\
-LH:\FP\2.6.0\UNITS\OS2\symbolic\
-LH:\FP\2.6.0\UNITS\OS2\rexx\
-LH:\FP\2.6.0\UNITS\OS2\regexpr\
-LH:\FP\2.6.0\UNITS\OS2\paszlib\
-LH:\FP\2.6.0\UNITS\OS2\pasjpeg\
-LH:\FP\2.6.0\UNITS\OS2\os2units\
-LH:\FP\2.6.0\UNITS\OS2\libpng\
-LH:\FP\2.6.0\UNITS\OS2\libgd\
-LH:\FP\2.6.0\UNITS\OS2\lexyacc\
-LH:\FP\2.6.0\UNITS\OS2\imlib\
-LH:\FP\2.6.0\UNITS\OS2\hermes\
-LH:\FP\2.6.0\UNITS\OS2\hash\
-LH:\FP\2.6.0\UNITS\OS2\gtk1\
-LH:\FP\2.6.0\UNITS\OS2\fv\
-LH:\FP\2.6.0\UNITS\OS2\fppkg\
-LH:\FP\2.6.0\UNITS\OS2\fpmkunit\
-LH:\FP\2.6.0\UNITS\OS2\fpgtk\
-LH:\FP\2.6.0\UNITS\OS2\fcl-xml\
-LH:\FP\2.6.0\UNITS\OS2\fcl-res\
-LH:\FP\2.6.0\UNITS\OS2\fcl-registry\
-LH:\FP\2.6.0\UNITS\OS2\fcl-process\
-LH:\FP\2.6.0\UNITS\OS2\fcl-passrc\
-LH:\FP\2.6.0\UNITS\OS2\fcl-net\
-LH:\FP\2.6.0\UNITS\OS2\fcl-json\
-LH:\FP\2.6.0\UNITS\OS2\fcl-js\
-LH:\FP\2.6.0\UNITS\OS2\fcl-image\
-LH:\FP\2.6.0\UNITS\OS2\fcl-fpcunit\
-LH:\FP\2.6.0\UNITS\OS2\fcl-db\
-LH:\FP\2.6.0\UNITS\OS2\fcl-base\
-LH:\FP\2.6.0\UNITS\OS2\chm\
-LH:\FP\2.6.0\UNITS\OS2\bzip2\
-LH:\FP\2.6.0\UNITS\OS2\
-LH:\FP\2.6.0\BIN\OS2\
H:\FP\2.6.0\UNITS\OS2\RTL\prt0.o
2 satsort.o
H:\FP\2.6.0\UNITS\OS2\RTL\system.o
H:\FP\2.6.0\UNITS\OS2\RTL\heaptrc.o
H:\FP\2.6.0\UNITS\OS2\RTL\sysutils.o
H:\FP\2.6.0\UNITS\OS2\RTL\strutils.o
H:\FP\2.6.0\UNITS\OS2\RTL\objects.o
H:\FP\2.6.0\UNITS\OS2\RTL\math.o
H:\FP\2.6.0\UNITS\OS2\RTL\crt.o
H:\FP\2.6.0\UNITS\OS2\RTL\dos.o
H:\FP\2.6.0\UNITS\OS2\RTL\objpas.o
H:\FP\2.6.0\UNITS\OS2\RTL\sysconst.o
H:\FP\2.6.0\UNITS\OS2\RTL\doscalls.o
H:\FP\2.6.0\UNITS\OS2\RTL\strings.o
H:\FP\2.6.0\UNITS\OS2\RTL\system.a
H:\FP\2.6.0\UNITS\OS2\RTL\crt.a
H:\FP\2.6.0\UNITS\OS2\RTL\doscalls.a
[---- fpc-link.res ends ----]

Do you see any error messages from the linker when running it from ppas.cmd created by fp.exe for compilation with -s?

see above... i can't get "fp -s" to make or leave a ppas.cmd behind :/

waldo kitty wrote

On 1/14/2012 16:49, Tomas Hajny wrote:

.
.

I don't know why they are different, but this probably shouldn't be a problem.

the second thing i note is the fp link.res messes up the directory we're working in for the program.o file being compiled whereas the fpc one doesn't say the directory but only the program.o... indicated with a 2 below...

.
.

2 h:\fpc\projects\satellite\h:\fpc\projects\satellite\satsort.o

.
.

This obviously is the problem - the linker cannot find the object file this way. :-((( I can reproduce it, but finding time for debugging it and fixing it will probably take some time (mostly due to time constraints on my side :-( ). Fortunately, the workaround of using the command line compiler works well so this shouldn't be a show-stopper (although it certainly isn't pleasant :-( ).

Thanks for letting me know about it. I suggest that you file a standard bug report (not that I expect anyone else to fix it if the problem is restricted to the OS/2 version, but it becomes visible for other users who may come across the problem too this way at least).

Tomas

i didn't think so, either... i mean, it would seem that fpc looks in the current directory already... as such, it doesn't list the .\ directory in its list... fp seems to need this additional assistance, maybe? ;)

i suspected that was the problem once i knew where to look... i'm glad you could reproduce it, too ;)

but finding time for debugging it and fixing it will probably take some time (mostly due to time constraints on my side :-( ).

i know how that is... i'm the maintainer of an add-on package for a popular firewall product and i haven't much time to work on that, recently, either :/

Fortunately, the workaround of using the command line compiler works well so this shouldn't be a show-stopper (although it certainly isn't pleasant :-( ).

yeah, 'about that :LOL: ah'ma gunna haf tah look at sumptin' tah see how tah tell fpc what ah wan' it tah do... like ah have set up in fp when compiling with the different modes :LOL

last time i did that was with TP/BP 6&7 and that was a looooooong time ago ;)

Thanks for letting me know about it. I suggest that you file a standard bug report (not that I expect anyone else to fix it if the problem is restricted to the OS/2 version, but it becomes visible for other users who may come across the problem too this way at least).

you are welcome... i will /try/ to do a bug report but i'm not sure where... i've done a few reports on these automated systems but, ha!, they still tend to confound me at times :P

/me adds "make a bug report" to the LOTTD (List Of Things To Do) and waddles off to try to figure out how to add an internal svn server to his small herd of boxen... :byebye:

On Sun, January 15, 2012 23:43, waldo kitty wrote: .
.

link.res is only used by the linker (invoked from both fpc and fp equally). Neither fpc nor fp use it themselves.

.
.

http://bugs.freepascal.org

Tomas

if we're lucky, it would be this one

http://bugs.freepascal.org/view.php?id=21100

i say lucky because i had to dance some rough hoops to get logged in... that was ugly because i already have/had an account on the wiki where i'd made some edits in the past few years... dunno what weird things were going on but it was not a pretty dance to dance :/