Although the Final Edition SDK announcement at the Hyperion web site claims that the SDK includes an "Updated clib2 alternative C standard library", it apparently wasn't updated to use renamed AmigaDOS functions. Here is an example of the link failures I'm getting:
/SDK/clib2/lib/libc.a(stdlib_program_name.o): In function `stdlib_program_name_init_ctor':
stdlib_program_name.c:(.text+0xe4): undefined reference to `GetProgramName'
make: *** [usbsnd] Error 1
GetProgramName() was renamed to GetCliProgramName() and including "dos/obsolete.h" in a program has no effect on a precompiled library like libc.a which contains obsolete function names. Unless someone has a fix for this problem, could we please get a new clib2 for the new SDK in AmiUpdate or uploaded to OS4Depot??
CLIB2 failures
CLIB2 failures
AmigaOne X1000 with 2GB memory - OS4.1 FE
Re: CLIB2 failures
You are best off posting this bug to the clib2 project: http://sourceforge.net/p/clib2/bugs/
The SDK simply provides a pre-compiled version.
The SDK simply provides a pre-compiled version.
Re: CLIB2 failures
I'm not sure if that is the right place to look anymore. Various people have moved the project to at least 3 different repositories at Github. After checking out all the clib2 repositories at Github, it looks like adtools/clib2 is the right one. Olaf Barthel made some changes there in July. Personally, I think that if clib2 is going to be included in the SDK then one of the OS4 devs should join the project, keep it up-to-date for OS4 and compile it for any SDK releases.chris wrote:You are best off posting this bug to the clib2 project: http://sourceforge.net/p/clib2/bugs/
The SDK simply provides a pre-compiled version.
I guess I'll just look for a workaround.
AmigaOne X1000 with 2GB memory - OS4.1 FE
- broadblues
- AmigaOS Core Developer
- Posts: 600
- Joined: Sat Jun 18, 2011 2:40 am
- Location: Portsmouth, UK
- Contact:
Re: CLIB2 failures
@xenic
clib2 itself is easy to build, IIRC, perhaps you could fix it an provide a patch.
clib2 itself is easy to build, IIRC, perhaps you could fix it an provide a patch.
Re: CLIB2 failures
@all
Actually, my workaround is to compile with the previous SDK. Whoever added clib2 to the previous SDK must have compiled it themselves (probably including <dos/obsolete.h>). The clib2 changes log indicates "tfrieden" made some of the original changes for OS4. I guess none of the other OS4 devs stepped in to keep it updated. I filed bug reports at the sf.net clib2 repository and the Github clib2 repository but that doesn't mean it will get fixed.
Actually, my workaround is to compile with the previous SDK. Whoever added clib2 to the previous SDK must have compiled it themselves (probably including <dos/obsolete.h>). The clib2 changes log indicates "tfrieden" made some of the original changes for OS4. I guess none of the other OS4 devs stepped in to keep it updated. I filed bug reports at the sf.net clib2 repository and the Github clib2 repository but that doesn't mean it will get fixed.
AmigaOne X1000 with 2GB memory - OS4.1 FE
Re: CLIB2 failures
I don't understand why this is a problem because we don't link by name.xenic wrote:GetProgramName() was renamed to GetCliProgramName() and including "dos/obsolete.h" in a program has no effect on a precompiled library like libc.a which contains obsolete function names. Unless someone has a fix for this problem, could we please get a new clib2 for the new SDK in AmiUpdate or uploaded to OS4Depot??
What is really going on here? Can you provide a full explanation with example?
Here is where clib2 lives now -> https://github.com/adtools/clib2
Can somebody tell us what is broken?
ExecSG Team Lead
Re: CLIB2 failures
It's a problem because when I compile this:ssolie wrote: I don't understand why this is a problem because we don't link by name.
Code: Select all
/* gcc -mcrt=clib2 test.c -o test */
#include <proto/exec.h>
#include <proto/dos.h>
int main(int argc, char **argv)
{
IDOS->Printf("Hello World\n");
return 0;
}
- /SDK/clib2/lib/libc.a(stdlib_program_name.o): In function `stdlib_program_name_init_ctor':
stdlib_program_name.c:(.text+0xe4): undefined reference to `GetProgramName'
I don't know anything about how we link but when I examined the file "stdlib_program_name.c" in the clib2 sourcecode at https://github.com/adtools/clib2, it contains the a call to the function "GetProgramName()" which is no longer present in "SDK:Include/include_h/interfaces/dos.h". It was replaced with "GetCliProgramName()". I could be wrong but I suspect that clib2 needs to be compiled with the SDK:Include/include_h/dos/obsolete.h" header file included.What is really going on here? Can you provide a full explanation with example?
Here is where clib2 lives now -> https://github.com/adtools/clib2
Can somebody tell us what is broken?
If I replace the new "libc.a" with libc.a from the previous SDK I don't get a link error with the above example source.
AmigaOne X1000 with 2GB memory - OS4.1 FE
- broadblues
- AmigaOS Core Developer
- Posts: 600
- Joined: Sat Jun 18, 2011 2:40 am
- Location: Portsmouth, UK
- Contact:
Re: CLIB2 failures
@xenic
but if you look at the commit logs on the github site you'll see Olaf added that header.
Could be it doesn't get included inot that one particular file somehow.
Just grab the source and build yourself a new copy.
but if you look at the commit logs on the github site you'll see Olaf added that header.
Could be it doesn't get included inot that one particular file somehow.
Just grab the source and build yourself a new copy.
- salass00
- AmigaOS Core Developer
- Posts: 530
- Joined: Sat Jun 18, 2011 3:12 pm
- Location: Finland
- Contact:
Re: CLIB2 failures
Compiling with -Werror as well as -Wall would have stopped this accident from happening.
With only -Wall gcc would have produced an "implicit declaration of function" warning but because it's not treated as an error it can be really easy to miss in a project with lots of files to compile such as clib2.
With only -Wall gcc would have produced an "implicit declaration of function" warning but because it's not treated as an error it can be really easy to miss in a project with lots of files to compile such as clib2.