CMake progress

@alfkil

I stumbled upon a problem where function always exists when it shouldn't, for example due to a linker failure. Below is a small example.

@Capehill

This is probably because the code, that does the test compile/link does not always give you the correct return code. I will have to look into that.

@alfkil

Thank you. One thing that happened on my system was that linker couldn't find libdl.so. I'm not sure why this is on the default lib list but even when removing it from the list (and linker giving undefined references xyz), CMake still thinks function exists.

@Capehill

How does this look? ;)

@alfkil

cmake 3.7.1 release version

I have the same problem as i had with the pre-release

The readme states
Quote:

I did not have this "Unix" path setting, there was no PATH at all set in ENV/ENVARC, so i did set it according to the readme.

After that it refused to build any of my ports though, i got this error message everytime (given the fact that the projects all share the same codebase it's no wonder they all break, but i don't know the reason)

Quote:
Where this is the line it breaks
Quote:

It's the ScummVM codebase, btw

Btw: It doesn't matter WHAT i put in $PATH, i can put the mentioned line in there, let it be completely blank or set it to some rubbish, as long as a PATH file is actually available in ENV/ENVARC the projects *will* fall over.
(I tried)

If i remove the setenv line and remove any PATH file from ENV/ENVARC, the projects do build again.

Not so sure about cmake projects, i haven't tried any yet, but i can't really work with this if it kills my gmake projects...

I don't have any AmiCygnix stuff, only the normal SDK initialization stuff.

Of course there could be stuff done while configuring my projects, but as i said, there is and was no PATH set et al before...something is rotten in the state of Denmark.

@Raziel

https://github.com/scummvm/scummvm/blob/master/Makefile.common

Can you debug the contents of DISTVERSION, a couple of lines above?

@alfkil

Cheers, will try it soon.

@Capehill

Not sure what you want me to do

@Raziel

Have you tried creating a new build directory and trying to rebuild from scratch?

EDIT: It doesn't seem, that the ScummVM sourcebase have any files named CMakeLists.txt. How exactly are you using CMake for this project, and are you sure it is the right way to do things? For instance, the error you mention doesn't seem to have anything to do with cmake.

@alfkil

i'm not using cmake to build scummvm.

my problem is that installing cmake (or better using $PATH) interferes with my gnumake ports.

if i cannot use cmake without losing the possibility to build gnumake projects or to always switch between using $PATH and not.

@Raziel

Ah, I completely misunderstood :).

Well, it must be a specific issue, there should be no reason why PATH should interfere with anything except things, that somehow relate to it in the wrong way.

My guess is that line 162 (or something similar) screws up, because gmake becomes confused about finding items. You might want to try running gmake from abc-shell or seeing, if anything in the path conflics with items, that are somehow needed by the build.

Could it be, that gmake has an internal search 'path' that is overruled by PATH if it is present?

EDIT: You could try running gmake on this makefile (from the same root position):

@alfkil

Quote:

I don't think gmake uses PATH directly, but as the primary difference between gmake and make is to use 'sh' instead of amigaos shell then you can be sure that it's using via 'sh'.

PATH belongs to abc-shell any other app that messes with had better follow abc-shell's rules.

One thing that could trip stuff up is that PATH being an environment variable is global, so if the global var is changed it effects everything, whereas on most *nix systems changing the var only affects child processes.

@Raziel

OK I'm seeing what the problem is now as I read the thread backwards ,
You need to set your PATH to something sane before you add the cmake stuff.

To see what you need to set it (at a minimum) delete it then start an abc-shell session.

then type

echo $PATH

If PATH exists abc-shell will use it, if it doesn't it installs a default, so you need to recreate that default if you create the global envvar PATH.


[edit]
My path is set like so

New Shell process 8
8.AmigaOS4:> echo $PATH
/gcc/bin:/SDK/C:/C
8.AmigaOS4:> sh
/AmigaOS4>echo $PATH
.:/SDK/Local/C:/SDK/Local/newlib/bin:/gcc/bin:/SDK/C:/C
/AmigaOS4>

Notice that although abc-shell adds a few things to the default path (this is in my .abc-rc file IIRC) it adds to the existing PATH. So at minimum if you define PATH externally tou need to add the abc-shell internal default which is

/gcc/bin:/SDK/C:/C

@alfkil

The new CMake fixed the issue I had. I just don't understand 1) why it wants to link with -ldl 2) why it doesn't find from SOBJS: where I have it?

My workaround was to remove -ldl for the time being (from CMake script).

Do you have a Paypal button somewhere?

@Capehill

Quote:

SOBJS: is not where the linker looks for shared objects, SDK:newlib/libs and SDK:Local/newlib/libs is. You need to have links from your SDK directories to the SOBJS: versions (or separate copies)

If your SDK has been updated few times these can get messed up.

AS a side issue there is no static version of libdl ie no libdl.a only a libdl.so so if your project is expecting to link statically whilst using libdl for loading modules or some such it can't work you have to link dynamically of build in modules statically.

@Capehill

That is great news.

Go to Modules/Platform/AmigaOS.cmake. Here you can add/remove standard libraries, include dirs and library locations. I added -ldl and -lunix by default, because they are needed to build CMake. You can safely remove those, if you don't need them, although they will be necessary for many CMake projects.

I don't have a paypal donation proceedure at the moment, if that's what you are asking about. I'd like to create something big and lustrous before I ask for people's moneys. If you need to throw money away, go for broadblues, he has been answering all the questions asked in this thread :).

Thanks, by the way! :)

@Capehill

"The new CMake fixed the issue I had."

Sorry, i missed this.

There's a new version of cmake?

@AmigaBlitter

Yes. Look on os4depot.net.

OK, thank you

Great work!

@alfkil @broadblues

I have also libdl.so (link) in the SDK. I mentioned SOBJS: because it's listed by CMake (or rather, /SObjs, see below). My problem with -ldl seems to be caused by CMake not using -use-dynld, thus GCC wants libdl.a. So I have to either add -use-dynld in CMake Amiga script or remove -ldl to workaround this.