No clue ... commandline to long ?

what if you issue the ppc command by hand ?

Marc

+ From: Peter Vreman
+
+ > I wrote:
+ > Added a makefiles target, when typed at the lazarus root,
+ > all makefiles are recreated if needed (pretty handy when
+ > you've changed a lot of makefile.fpc files :)
+
+ I always use "fpcmake -w `find . -name Makefile.fpc`"

Less typing :-)

+ > Note 1: If you want to create the makefiles yourself
+ > (ie running fpcmake) you (for this moment) need
+ > the fpc sources.
+
+ With the latest 1.0.5 install includes Package.fpc for each
+ unit directory. This file can
+ also be used to build a Makefile for a single target using
+ "fpcmake -T<target> -w".

Ah. while looking at the fpcmake sources I already got the idea that this should be possible.

+ > Note 2: You need the latest (thus not the FIXEX tree) of
+ > fpcmake, this one is currently not in the
+ > fpc.1.0.5.laz package (I'll update that one someday) +
+ The fpcmake available in the 1.0.5 tree is the same as the
+ one in the 1.1 tree. Maybe an update of the tag is required to
+ update it to the current 1.1 version.

With the last check, not all changes have the FIXES_1_0_0 tag. The 1.0.5 version I create is baset upon that tag, so in the last rpm I created these changes for fpcmake weren't there.

Marc

How is fpcmake called ? Is the -T in the arguments ?

Ok first some history:

* We needed a new compiler (forgot why)

* This version doesn't support the -Ca flag we
need for lazarus (it's buildin now)

* This flag had to be removed from the makefiles,
which is easies done by editing the Makefile.fpc
and running fpcmake.

* There is a new, improved version of fpcmake, which doesn't support the old syntax. And generates newstyle Makefiles

* fpcmake analyses requied fpc packages by source or by Package.fpc. The latter wasn't shipped in the last rpm so in that case you need sources.

Now our promblems:

- windows won't build.
Since you are using an old compiler
it needs the -Ca flag. You can work around this by providing this flag with OPT. IE make OPT=-Ca

- installations fail
The new install part of the Makefile generates package info with the use of fpcmake. Since the fpcpackage info is missing in the rpm version, sources were needed. This is a bug in the 'make rpm', since they are included in the 'make linuxzip'. I'll upload the new *.tar.gz and may can someone look at what goes wrong in 'make rpm' As other fix I'll upload the missing package.fpc files.

Marc

Michael A. Hess wrote

I will still have to try to build the ide manually but it won't build via the 'make ide' command. It throws that no source thingy.

if you have all paths correct in your ppc.cfg the lcl and components are build then you can issue
ppc386.exe -Fu. -Fu./designer -Fu./debugger -Fi. -Fi./include -Fi./include/win32 lazarus.pp
manually

+ From: Keith Bowes
+ Sent: Thursday, 16 August, 2001 11:50
+ To:
+ Subject: Re: [lazarus] CVS Changes
+
+
+ I experienced somewhat of a problem when I tried to use the
+ new make from the FTP. All compiled fine but when I ran
+ lazarus, I got the following message:
+ An unhandled exception occurred at 0x0049C89A :
+ Abstract method called
+ 0x0049C89A TAPPLICATION__INITIALIZE, line 132 of
+ ./include/application.inc
+ 0x00401036 main, line 83 of lazarus.pp
+ 0x004D7291
+
+ forms.pp - finalization section

It looks like you have the wrong interfaces.ppu. What exactly did you compile ?

+ When I use the make from the FPC 1.0.4 release with the
+ variable USEENV=1, it compiles fine and runs normally.

Hmm.... AFAIK lazarus won't compile with the 1.0.4 compiler.

Marc

The fpcmake found in the RPM is NOT the same as the version found in your tar.gz files. The one in the RPM doesn't know what -T is but the one in the tar.gz file does. I tried to use that one and I have gotten much further. :-)

The only hickup I had was that it errored trying to work with the lazarus/dist directory. I didn't have any such directory so it blew up. Once I created that directory then everything finally worked.

Yah. :-)

Now to figure out the Win32 problems. :-\

+ From: Peter Vreman
+
+ Strange. Using the -T<target>[,target] should only build a
+ Package.fpc for the specified targets without requiring the
+ other targets. The Makefiles should have -T$(OS_TARGET) in
+ the line where it calls fpcmake.

Not really strange, I was testing fpcmake without the use of a makefile (thus without the -T option :)

Marc

HUH, this happens when you do a make in the lazarus dir ?

What compiler are you using ? The bin 1.0.5 of august ?

Marc

No, I didn't say the 1.0.4 compiler, I said the version of "make" that is included with the 1.0.4 compiler.

I originally did a complete release installation of the 1.0.4 compiler then got the source out of CVS and rebuilt the compiler so that it was 1.0.5 but the utilities are still the 1.0.4 release version.

Just to refresh memory this is a Win32 issue.

+ From: Michael A. Hess
+
+ No that one was taken care of with the USEENV=1 option. The
+ error I was getting was the:
+
+ --------------------------------------
+ Compiling lazarus.pp
+ Linking lazarus.exe
+ -: final link failed: Permission denied
+ lazarus.pp(121,1) Warning: Error while linking
+ --------------------------------------
+
+ I don't get this one. Permission denied? What permissions?

While thinking of this... is there a file readonly ?

Marc

Michael A. Hess wrote

I thought of that one. So I just did a 'make ide' without the OPT=-Ca and it still gave me the same error.

What error... the no source file error ? (or that one with interfacebase)

Again without the OPT=-Ca this is the same thing that worked on Monday morning so again it must relate to some change in the Makefile. :-\

There is a lot changed in the makefiles, but the commandline isn't changed I think. Only how things are build.

Marc

Marc Weustink wrote

This morning I realized that you are probably using a fpc rpm of 20010802 or 20010613. Maybe the Package.fpc support is added later. So can you try the 20010815 version. It contains the latest fpcmake.

This still didn't work. I had to go through a few hoops to get the RPM to install (won't explain) but I have now installed the 20010815 version of the binary release of FPC. I confirmed that it did install a new version of fpcmake as well.

When I do a build I still get exactly the same error with the fpcmake call ...

An unhandled exception occurred at 0x0805ED78
s_package_not_found rtl
0x0805ED78
0x00000000

It is looking more and more like I MUST have the FPC source to make things work. :-\

Correct. It is not possible to detect the platform of make.exe so you need to specify it by hand if you want to use the environment for passing the options.

So you'll get:

make USEENV=1 OPT=-Ca

Or take the makew32.zip from the win32-1.0.6/separate/ dir from the fpc ftp and use the native win32 tools.

Now I am really confused. This is attempting to build a installation for Lazarus and Lazarus only. It shouldn't care about the do you currently need the compiler source to just build an install of the Lazarus application and units. It doesn't even include the compiler units and shouldn't.

I'm not an fpcmake expert by a long shot so maybe you can explain exactly what it is trying to do. :-\

That's what I am going to try but probably not until tomorrow morning. My head hurts. Time to call it a day.

the makew32.zip from 1.0.4 release contained go32v2 binaries for make.exe and the fileutils (cp.exe, mv.exe, etc.) All those tools were required to be go32v2 because of the commandline length problems. So including a win32 make.exe and having a go32v2 cp.exe was not possible.

Now we've finally managed to get all utils as native win32 (not cygwin) binaries. We've made them already available as for win2000 those are required, see the FAQ.

The USEENV=1 is required because the check for OS_TARGET==win32 has been removed. In the previous Makefile when compiling for win32 would implicitly toggle the usage of the environment for passing options.

But with the new fpcmake and the newly available makew32 it was also possible to use a go32v2 compiler and using win32 make, and that also has the commandline length problem and thus the usage of the environment. When this was added like the old way a check for OS_TARGET==go32v2 would be necessary.

Having both a check for OS_TARGET=go32v2 and OS_TARGET=win32 in the makefile would always call the compiler using the environment under Win32/Dos. Also using the go32v2 make.exe and go32v2 compiler.exe.

If it was possible to check for which target make.exe was build it would be possible to add autodetection again. But a simple way of detecting it is not possible.

The no source file error. The OPT=-Ca took care of the interfacebase error. It builds all the units but when it tried to compile lazarus.pp basically the IDE itself is when I get the strange no source error. This is only on Win32 by the way. Linux builds, links, etc. and only fails on the make install stuff.

I will still have to try to build the ide manually but it won't build via the 'make ide' command. It throws that no source thingy.

Did this.

* Extract the missing packages tag.gz in the lib/fpc/1.0.5 dir.

I assume you mean extract so it creates all the directories with just the Package.fpc files in them. Did this.

Same problem. Nothing changed.

Peter Vreman wrote

> I guess what has me confused is why would it build binaries for > months using the current setup.

<snip>

The USEENV=1 is required because the check for OS_TARGET==win32 has been removed. In the previous Makefile when compiling for win32 would implicitly toggle the usage of the environment for passing options.

Ahhh. Now I got it. Now I understand why a change in the makefile caused things to go snafu. Thank you. :-)

I'll upgrade everything on the Win32 box as well. Now I have to see what happens with it and the packaging problem. :-\

I thought of that one. So I just did a 'make ide' without the OPT=-Ca and it still gave me the same error. Again without the OPT=-Ca this is the same thing that worked on Monday morning so again it must relate to some change in the Makefile. :-\

what if you issue the ppc command by hand ?

I'll give it a try but that doesn't help me out with the cron'ed builds every night. :-\

Becuase we've now also native win32 tools the using environment for passing options is not required anymore. But it is not possible to detect if you are using the go32v2 make.exe or the win32 make.exe. So you need to specify the USEENV=1 option manually when you are 'cross' compiling.

Marc Weustink wrote

It took some time, but I finally updated the makefiles.

More problems but now with the nightly Linux build. It seems to build the program just fine but blows up trying to do the zipinstall.

For some reason the next thing after the

make -C lcl install

it tries to run fpcmake to build the makefile in the lcl directory which it has already processed. :-\

What gives?????

From the error message Keith gave I wasn't convinced he had the same problem as you (He has problems running lazarus).

Marc

+ Marc Weustink wrote:
+ >
+ > This morning I realized that you are probably using a fpc rpm of
+ > 20010802 or 20010613. Maybe the Package.fpc support is
+ > added later. So
+ > can you try the 20010815 version. It contains the latest fpcmake. +
+ This still didn't work. I had to go through a few hoops to get the RPM
+ to install (won't explain) but I have now installed the
+ 20010815 version
+ of the binary release of FPC. I confirmed that it did install a new
+ version of fpcmake as well.
+
+ When I do a build I still get exactly the same error with the fpcmake
+ call ...
+
+ An unhandled exception occurred at 0x0805ED78
+ s_package_not_found rtl
+ 0x0805ED78
+ 0x00000000
+
+ It is looking more and more like I MUST have the FPC source to make
+ things work. :-\

Ok, I'll try this at home. (rename the fpc dir). I can't see how fpcmake knows my source fpcdir. (it is exported to /usr/lib/fpc = no sources)

Marc

Marc Weustink wrote

It took some time, but I finally updated the makefiles.

Something got hosed. My nightly build broke. Something is amiss with finding units. The interface.pp file in gtk can't seem to find the interfacebase unit even though it is already built and in the units directory.

OK this sort of worked. But again I ask what changed????

I have been building win32 nightly binary releases for months with the same setup. Changes are made to makefile and now the whole thing goes bust. I never had a commandline to long before so what changed?

Now I said the above worked sort of. While it now compiles it blows up on the link with ...

Compiling lazarus.pp
Linking lazarus.exe
-: final link failed: Permission denied
lazarus.pp(121,1) Warning: Error while linking

What gives with this. Permission denied? What permissions?

Or take the makew32.zip from the win32-1.0.6/separate/ dir from the fpc ftp and use the native win32 tools.

OK you lost me here. If I am not already using the native win32 tools then what am I using?????

I got this error under linux and the reason was an invalid write access in one of the initialization sections (misuse of shortstring/ansistring). By just adding a writeln('bogus'); in TApplication.Initialize proc the error 'disappeared'. If your error disappears or moves by just adding some writelns then there is still a bug left.

Mattias Gaertner

Marc Weustink wrote

HUH, this happens when you do a make in the lazarus dir ? What compiler are you using ? The bin 1.0.5 of august ?

No but this is the Win32 version that I am talking about. I haven't built a new release of that.

However in both of the errors that I have mentioned for Win32 and Linux everything built fine on Monday morning but this morning it failed on both platforms with the afore mentioned errors.

See the FPC faq :-)

http://www.freepascal.org/faq.html#makefilewin2000

New version of fpcmake generates a new version of Makefiles, which generate package info.

Why does it need to run fpcmake at all? I thought if the makefile is already built you shouldn't need fpcmake.

fpcmake is now also used the generate packaging info if the package you are zipping. Is *doesn't* generate a makefile, it generates a Package.fpc

OK, I'll look what will be faster, stripping the pachagi info from the makefiles or building a new compiler which has (if I understood it well) separate Package.fpc files so you don't need the sources.

Now I assume that the error is due to the fact that I have an old version of fpcmake on my machine but I should even need it should I?

Nope, you have a new one, it tries to read rtl dependencies.

Eehhh.... maybe I was a bit to optimistic here :-)

However in both of the errors that I have mentioned for Win32 and Linux everything built fine on Monday morning but this morning it failed on both platforms with the afore mentioned errors.

That makes sence, since I changed makefiles yesterday eve (= your yesterday afternoon).

Marc

+ From: Michael A. Hess
+
+ Exactly what should the line look like and is there something
+ I can try outside of the makefile to see if it works? You know
+ calling it myself with
+
+ fpcmake {whatever}

fpcmake -p -v -Tlinux

BTW did you export FPCDIR=/usr/lib/fpc/1.0.5 ?

+ When I run fpcmake by itself it doesn't list -T as a valid argument.
+ Should it?

I think so ....

marc:~/lazarus$ fpcmake
fpcmake: <-pw> [-vqh] [file] [file ...]
Operations:
-p Generate Package.fpc
-w Write Makefile

Options:
-T<target>[,target] Support only specified targets -v Be more verbose
-q Be quiet
-h This help screen

Did you install the 1.0.6 binary tools? (The thingy from the faq?)

Hi all,

I'm going on holliday for a week, is there any possibility to set my list settings to weekly digest or do I have to unsubscribe for a week so that my mailbox doesn't overflood?

Thanks!

He was commenting on the fact that he had the same error as I did but the statement you are answer was from my email. :-)

From the "FPC 1.0.4 release" part I assumed a 1.0.4 compiler was used. Since this is strange I suspected a mix of versions, where all kinds of errors are possible. Before digging into sources I want to be sure the latest version of Lazarus is used.

Again this all goes back to the changed makefile business. On the Monday before the change Win32 builds went of without a hitch. The next day after the makefile changes it doesn't build. No change to the compiler was made in fact when I checked little to no changes were made to any of the source it was just the makefile that changed.

I can only assume that it changed some dependencies or requiresments or something that now makes the Win32 build fail. :-\

The thread is getting a bit long and it was some time since you had added to the thread so that is why I added the memory refresh. :-)

Hi,

It took some time, but I finally updated the makefiles. Changes are only internal (for the new fpcmake version), so no much change if you only type make.

Added a makefiles target, when typed at the lazarus root, all makefiles are recreated if needed (pretty handy when you've changed a lot of makefile.fpc files :)

Updated the win32 target.

Note 1: If you want to create the makefiles yourself (ie running fpcmake) you (for this moment) need
the fpc sources.
Note 2: You need the latest (thus not the FIXEX tree) of fpcmake, this one is currently not in the
fpc.1.0.5.laz package (I'll update that one someday) Note 3: Don't set the FPCDIR in the makefiles if you commit them to CVS. You can point to the FPCDIR by issuing export FPCDIR=your/path/to/fpc
(or DOS: set FPCDIR=your/path/to/fpc).
This is only needed when running fpcmake
(and probably make zipinstall I guess)

TIP: I created a small script lazmake where I set the FPCDIR, run fpcmake and unset FPCDIR. This way you can run fpcmake with the fpc sources and build lazarus with the fpc-binaries (with FPCDIR set, the compiler will be build first)

Marc

However informative this is it doesn't apply. I am not using Win2000/NT I am using Win98SE.

you wrote

The fpcmake found in the RPM is NOT the same as the version found in your tar.gz files. The one in the RPM doesn't know what -T is but the one in the tar.gz file does. I tried to use that one and I have gotten much further. :-)

HUH ? AFAIK I've made them from the same sources. I've to check this.

The only hickup I had was that it errored trying to work with the lazarus/dist directory. I didn't have any such directory so it blew up. Once I created that directory then everything finally worked.

Oops... that one I forgot to create :)

Yah. :-) Now to figure out the Win32 problems. :-\

Still the comandline ?

Marc

It is not creating the makefiles, it is creating the package info. (other cmdline switch)

What version of fpcmake are you using ?
Try to set FPCDIR to the fpc sources when running make zipinstall. Does it make a difference ?

MArc

So you are saying that the previous 1.0.4 Win32 release didn't have a make specifically for win32 but it was some sort of generic make?

I guess what has me confused is why would it build binaries for months using the current setup. Then on Tuesday after some modifications to the makefile that were made on Monday nothing works. I didn't change the compiler, make, nothing except those file changes made to the Lazarus code and it's makefile and now you say that the make.exe is what is wrong. Just has me confused. So you see my question is what happened to the makefile on Monday that suddenly required me to use USEENV=1 when I never had to in the past?

Marc Weustink wrote

BTW did you export FPCDIR=/usr/lib/fpc/1.0.5 ?

Yes awhile ago. The fpcmake -v -w reports correctly.

When I run it I do NOT get the -T option indicated. I get an illegal option if I try to add the -T to the command string. I am running the version of fpcmake that you included in the RPM. Is that the problem?

Marc Weustink wrote

It is not creating the makefiles, it is creating the package info. (other cmdline switch)

It never did this before why is it doing it now? Why does it need to run fpcmake at all? I thought if the makefile is already built you shouldn't need fpcmake.

What version of fpcmake are you using?

I don't know but I shouldn't even need it should I?

Try to set FPCDIR to the fpc sources when running make zipinstall. Does it make a difference ?

I don't have the FPC sources online at this point in time. I haven't for the last few months. I am using the binary installation.

Here is what is showing up in the log.

.
.
.
make -C lcl install
make[2]: Entering directory `/home/opt/lazarus/lcl' /usr/bin/fpcmake -p Makefile.fpc
Processing Makefile.fpc
An unhandled exception occured at 0x0805ED78 :
s_package_not_found rtl
0x0805ED78
0x00000000

Now I assume that the error is due to the fact that I have an old version of fpcmake on my machine but I should even need it should I?

Pfffff..... found it :-)

When fpcmake (version 20010815) tries to write a Package.fpc file it wants to check all platforms (it hasn't this behaviour when writing Makefiles, which I used to check).
When searching for Package.fpc it looks in the lib/fpc/1.0.5 dir and the lib/fpc/1.0.5/units/[platform] dir. The tar.gz with the missing Package.fpc files was extracted in the lib/fpc/1.0.5/units/linux dir, so when writing the package file it wants also to have a rtl/Package.fpc in the go32v2 dir (and all other platform dirs).
That was where your missing rtl error was from.

Solution:
* Remove all Package.fpc files from the lib/fpc/1.0.5/units/linux/* dirs (in the dir: rm `find -name Package.fpc`)
* Extract the missing packages tag.gz in the lib/fpc/1.0.5 dir.

By trying to fix this problem I ran into a fpcmake bug (?) When there is a Package.fpc in both lib/fpc/1.0.5/[package] and lib/fpc/1.0.5/units/[platform]/[package], fpcmake also reports an error of a missing [package]. Somehow internally it returns both dirs as one.

Marc

OK, a new binary compiler version is available, in both tar.gz as rmp form. When using the rpm version, please untar the
use_these_missing_rpm_packagefpc.20010815.tar.gz in the /usr/lib/fpc/1.0.5/units/linux dir.

ftp://www.lazarus.freepacal.org/lazarus/

Marc

Ehh... indeed (did you say that ? The message was from another poster :)

From the "FPC 1.0.4 release" part I assumed a 1.0.4 compiler was used. Since this is strange I suspected a mix of versions, where all kinds of errors are possible. Before digging into sources I want to be sure the latest version of Lazarus is used.

That wasn't clear from the message I replied to.

Marc

Marc Weustink wrote

>Now to figure out the Win32 problems. :-\ Still the comandline ?

No that one was taken care of with the USEENV=1 option. The error I was getting was the:

--------------------------------------
Compiling lazarus.pp
Linking lazarus.exe
-: final link failed: Permission denied
lazarus.pp(121,1) Warning: Error while linking
--------------------------------------

I don't get this one. Permission denied? What permissions?

I still want to cycle a new Win32 compiler and try some more stuff. I sort of put it on the back burner trying to get the Linux version running first.

Peter Vreman wrote

How is fpcmake called ? Is the -T in the arguments ?

I looked through the makefile but it doesn't appear to use the -T argument as far as I can tell. (I never was too good at reading makefiles) :-)

Exactly what should the line look like and is there something I can try outside of the makefile to see if it works? You know calling it myself with

fpcmake {whatever}

When I run fpcmake by itself it doesn't list -T as a valid argument. Should it?

----- Original Message -----

Strange. Using the -T<target>[,target] should only build a Package.fpc for the specified targets without requiring the other targets. The Makefiles should have -T$(OS_TARGET) in the line where it calls fpcmake.

That's indeed the bug. I need to add $(firstword ) to the routine to only return the first found version.

I always use "fpcmake -w `find . -name Makefile.fpc`"

With the latest 1.0.5 install includes Package.fpc for each unit directory. This file can also be used to build a Makefile for a single target using "fpcmake -T<target> -w".

To create a Makefile for all targets you are always required to have the full source tree installed, because some targets don't have specific packages that are required for other targets.

Note 2: You need the latest (thus not the FIXEX tree) of fpcmake, this one is currently not in the fpc.1.0.5.laz package (I'll update that one someday)

The fpcmake available in the 1.0.5 tree is the same as the one in the 1.1 tree. Maybe an update of the tag is required to update it to the current 1.1 version.

Almost...

I added the OPT=-Ca which got me alot further but now it stops with the following:

c:/pp/bin/win32/make.exe --assume-new=lazarus.pp lazarus.exe make.exe[1]: Entering directory `c:/opt/lazarus'
ppc386.exe -gl -Fu. -Fu./lcl/units -Fu./lcl/units/gtk -Fu./components/units -Fu./designer -Fu./debugger -Fi. -Fi./include -Fi./include/win32 -Ca -di386 lazarus.pp
Free Pascal Compiler version 1.0.5 [2001/01/15] for i386 Copyright (c) 1993-2000 by Florian Klaempfl
Fatal: No source file name in command line
make.exe[1]: Leaving directory `c:/opt/lazarus'

Do you know what gives with this???

Can you email me the files with a little info about where to put them so that a build will go off tonight?

No. Only the USEENV=1 is then required when compiling using the win32 compiler.

http://www.miraclec.com/list_archives/lazarus/msg00865.html

----- Original Message -----

hey you guys

why is the [lazarus] missing in subject ???

my filter send mail to wrong mailadress !

The fpcmake found in the RPM is NOT the same as the version found in your tar.gz files. The one in the RPM doesn't know what -T is but

the

one in the tar.gz file does. I tried to use that one and I have

gotten

much further. :-) The only hickup I had was that it errored trying to work with the lazarus/dist directory. I didn't have any such directory so it blew

up.

"Michael A. Hess" wrote

Not yet but I thought that was a Win NT/2000 issue. It should affect Win98 should it?

The last should have said:

It shouldn't affect Win98 should it?

Marco van de Voort wrote

Did you install the 1.0.6 binary tools? (The thingy from the faq?)

Not yet but I thought that was a Win NT/2000 issue. It should affect Win98 should it?